Вразливість WordPress CVE-2026-119977: Сайти, зламані під час оновлень, та як захистити свій

Наприкінці жовтня 2026 року в механізмі оновлення WordPress було виявлено вразливість: CVE-2026-119977 . Вона дозволяє зловмиснику без логіна та пароля виконувати довільний код на сервері — але лише під час оновлення сайту. Ця вразливість вже використовується в реальних атаках.

Нижче описано, як це працює, на кого це впливає та що робити для захисту вашого сайту.

Коротко про вразливість

• Що це: умова змагання (клас TOCTOU) у повному процесі оновлення ядра WordPress.
• Тяжкість: CVSS 8.1 (Високий).
• Зачеплені версії: WordPress з версій 4.7 по 7.1.3 включно.
• Що потрібно зловмиснику: лише HTTP-доступ до сайту. Автентифікація та дії адміністратора не потрібні.
• Експлуатація: 3 листопада 2026 року CISA додала цю вразливість до свого каталогу відомих експлуатованих вразливостей (KEV). Wordfence зафіксував понад 18 500 запитів до вразливих шляхів протягом перших 21 години після розкриття деталей.

Як працює атака

Під час повного оновлення ядра WordPress виконує наступне:

1. Завантажує архів з новою версією.
2. Розпаковує його до тимчасової папки всередині wp-content/upgrade/.
3. Копіює файли поверх активного сайту.
4. Видаляє тимчасову папку.

Проблема полягає в тому, що тимчасова папка знаходиться за адресою передбачуваний шлях і доступний з браузераУсередині знаходиться повна копія WordPress, включаючи setup-config.php інсталятора.

Під час виконання оновлення зловмисник може відкрити цей інсталятор та пройтися через нього. В результаті вони можуть замінити активний wp-config.php і вказати сайт на власну порожню базу даних. Потім WordPress пропонує «встановлення» — зловмисник завершує його, стає адміністратором і запускає власний PHP-код на сервері.

Вікно атаки – це кілька секунд, які займає оновлення. Це ускладнює виконання атаки на практиці, але масові сканери постійно досліджують вразливі шляхи, розраховуючи саме на цей час, щоб вирівнятися.

Версія 7.1.4 рандомізує назву тимчасової папки, додає захист від прямого доступу та блокує перенесення конфігурації з тимчасової копії.

Хронологія

Фіксовані версії

Виправлення було портовано до кожної підтримуваної гілки аж до версії 4.7. Ми рекомендуємо оновити систему до останньої версії, 7.1.4.

Версії 4.6 та старіші не отримали виправлення. Ці сайти потрібно оновити до поточної версії або вивести з експлуатації.

Крок 1. Перевірте свою версію WordPress

В адміністративній панелі: Панель керування → Оновлення . Не покладайтеся на автоматичні оновлення — можливо, вони не запустилися: їх могли вимкнути, завершити збій через дозволи на файли або перевизначити плагіном.

За допомогою WP-CLI:

wp core version

Якщо у вас кілька сайтів на сервері, ви можете знайти кожну інсталяцію WordPress та її версію ось так:

find /var/www -path '*/wp-includes/version.php' -exec grep -H "wp_version =" {} \;

заміщати /var/www з каталогом, де знаходяться ваші сайти.

Крок 2. Заблокуйте доступ до wp-content/upgrade/ (для VPS та виділених серверів)

Це найважливіший захід. Він закриває вікно атаки незалежно від вашої версії WordPress і не заважає оновленням: WordPress працює з цією папкою через файлову систему, а не через Інтернет. Зробіть це перед оновленням, оскільки атака відбувається саме під час оновлення.

Nginx

Додайте це до свого сайту server блок:

location ^~ /wp-content/upgrade/ {
    deny all;
}

Перевірте конфігурацію та перезавантажте nginx:

nginx -t && systemctl reload nginx

Apache та LiteSpeed

Додайте це до .htaccess файл у кореневому каталозі сайту, вище стандарт # BEGIN WordPress блок:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^wp-content/upgrade/ - [F,L]
</IfModule>

Якщо у вас є доступ до конфігурації віртуального хоста Apache, надійніше заблокувати каталог там:

<Directory "/var/www/example.com/wp-content/upgrade">
    Require all denied
</Directory>

Замініть шлях на свій власний та перезавантажте Apache:

apachectl configtest && systemctl reload apache2

На AlmaLinux, Rocky та інших системах на базі RHEL ця служба називається httpd.

Перевірте, чи працює блок

curl -I https://example.com/wp-content/upgrade/

Відповідь повинна повернути код 403.

Крок 3. Зробіть резервну копію

Перед оновленням створіть резервну копію файлів сайту та бази даних. За допомогою WP-CLI:

wp db export ~/backup-$(date +%F).sql
tar -czf ~/site-files-$(date +%F).tar.gz -C /var/www/example.com .

Якщо у вас є VPS, ви також можете зробити знімок сервера в панелі керування.

Крок 4. Оновіть WordPress

Через адміністративну панель або WP-CLI

Якщо ви заблокували доступ до wp-content/upgrade/ (Крок 2), оновлюйте як завжди — з адміністративної панелі або через WP-CLI:

wp core update
wp core update-db
wp core version

Остання команда повинна показати 7.1.4 або виправлену версію для вашої гілки.

Вручну, без вікна атаки

Якщо ви не можете заблокувати доступ до каталогу на рівні веб-сервера (наприклад, у вас немає доступу до його конфігурації), безпечніше оновлювати вручну. Архів розпаковується за межі кореневого каталогу сайту, а файли копіюються без дотику. wp-config.php or wp-content:

cd /tmp
wget https://wordpress.org/latest.tar.gz
tar -xzf latest.tar.gz
rsync -a --exclude 'wp-content' --exclude 'wp-config.php' /tmp/wordpress/ /var/www/example.com/
rm -rf /tmp/wordpress /tmp/latest.tar.gz

Потім відновіть право власності на файл (користувач веб-сервера може відрізнятися, наприклад nginx or apache) та оновіть базу даних:

chown -R www-data:www-data /var/www/example.com
wp core update-db

Замість останньої команди можна відкрити https://example.com/wp-admin/upgrade.php у веб-переглядачі.

Не забувайте про плагіни та теми

wp plugin update --all
wp theme update --all

Крок 5. Перевірте свій сайт на наявність ознак компрометації

Якщо ваш сайт було оновлено з вразливої ​​версії після 28 жовтня, переконайтеся, що ніхто не скористався атакою.

Запити до тимчасових інсталяторів у журналах:

# nginx
grep -E "wp-content/upgrade/.*\.php" /var/log/nginx/access.log*

# Apache
grep -E "wp-content/upgrade/.*\.php" /var/log/apache2/access.log*

Запити з 200 код відповіді є особливо підозрілим.

Замінений wp-config.php: перевірте дату модифікації файлу та налаштування підключення до бази даних.

ls -l /var/www/example.com/wp-config.php
grep -E "DB_(NAME|USER|HOST)" /var/www/example.com/wp-config.php

Цілісність основного файлу:

wp core verify-checksums

Незнайомі PHP-файли та адміністратори:

find /var/www/example.com/wp-content/upgrade /var/www/example.com/wp-content/uploads -name "*.php"
find /var/www/example.com -name "*.php" -mtime -10
wp user list --role=administrator

Якщо ви знайдете заміну wp-config.php, незнайомих адміністраторів або неочікувані PHP-файли, розглядайте сайт як скомпрометований. Відновіть його з резервної копії, створеної до 28 жовтня, оновіть WordPress та змініть усі паролі: адміністратора, бази даних, FTP та SSH.

Якщо підрядник обслуговує ваш об'єкт

Перешліть їм цю статтю та попросіть підтвердити, що сайт оновлено до виправленої версії та перевірено на наявність ознак компрометації.

Потрібна допомога?

Не впевнені, що зможете впоратися з цим самостійно, або знайшли підозрілі файли? Зверніться до нашої служби підтримки — ми допоможемо вам розібратися.