Уразливості WordPress уже використовують в атаках: які версії оновити

Дві уразливості WordPress Core уже використовують у реальних атаках. Власникам сайтів на гілках 7.0, 6.9 і 6.8 варто не чекати наступного планового обслуговування, а перевірити точну версію та встановити виправлення.

17 липня команда WordPress випустила WordPress 7.0.2 і захисні оновлення 6.9.5 та 6.8.6. Реліз закриває дві пов’язані проблеми безпеки, а через їхню серйозність WordPress увімкнув примусові фонові оновлення для вразливих установок. Це не гарантує, що оновився кожен сайт: автоматичний процес може не спрацювати через права на файли, конфігурацію хостингу або вимкнені оновлення.

Чому попередження стало терміновим

21 липня американське агентство CISA додало обидві уразливості до каталогу Known Exploited Vulnerabilities. Потрапляння до KEV означає, що агентство має докази їх експлуатації, але не означає, що зламано всі сайти WordPress. CISA не назвала кількість жертв, конкретне угруповання чи підтверджену кампанію програм-вимагачів.

Для федеральних цивільних відомств США CISA встановила строки усунення: 24 липня для CVE-2026-63030 і 4 серпня для CVE-2026-60137. Це службові дедлайни американських відомств, а не загальний юридичний строк для приватних власників сайтів.

Що роблять CVE-2026-60137 і CVE-2026-63030

CVE-2026-60137 стосується параметра author__not_in у WP_Query. Ядро недостатньо очищало значення, тому SQL-ін’єкція ставала можливою, коли плагін або тема передавали до цього параметра неперевірені дані. Це важлива умова: сама наявність WordPress 6.8 не означає, що будь-який відвідувач автоматично отримував виконання коду.

CVE-2026-63030 — конфлікт обробки маршрутів у пакетному endpoint REST API. У WordPress 6.9 і 7.0 його можна поєднати з першою уразливістю, обійти очікувану перевірку параметрів, виконати SQL-ін’єкцію та зрештою отримати віддалене виконання коду. Саме ланцюжок двох помилок створює найнебезпечніший сценарій. WordPress 6.8 уразливий до CVE-2026-60137, але не до CVE-2026-63030.

Які версії потрібно оновити

Встановлена версія	Що її стосується	Мінімальне виправлення
7.0.0–7.0.1	Обидві CVE	7.0.2
6.9.0–6.9.4	Обидві CVE	6.9.5
6.8.0–6.8.5	Лише CVE-2026-60137	6.8.6
Раніше за 6.8	Не зачіпають саме ці дві CVE	Перехід на актуальну підтримувану версію

Фраза «версії до 6.8 не зачіпають ці CVE» не робить старі гілки безпечними. WordPress нагадує, що активно підтримується лише найновіший реліз. Якщо великий перехід потребує перевірки сумісності, спочатку негайно встановіть виправлення своєї гілки, а потім окремо заплануйте оновлення до актуальної версії.

Що зробити власнику сайту зараз

1. Перевірте версію. В адмінпанелі відкрийте «Майстерня → Оновлення». За наявності WP-CLI виконайте wp core version. Не орієнтуйтеся лише на лист від хостингу або повідомлення про автоматичне оновлення.
2. Зробіть перевірену резервну копію. Збережіть базу даних і файли, переконайтеся, що архів відкривається та доступний поза сервером. Для постійного захисту підійде схема резервних копій 3-2-1.
3. Оновіть ядро. Для 7.0 встановіть 7.0.2, для 6.9 — 6.9.5, для 6.8 — 6.8.6. Оновлення плагіна безпеки або правило WAF не замінюють офіційне виправлення ядра.
4. Оновіть плагіни й теми. Перша CVE залежить від того, як розширення передає дані до WP_Query. Оновлене ядро закриває описану проблему, але не усуває окремі уразливості застарілих розширень.
5. Перевірте результат. Знову відкрийте сторінку оновлень, перевірте головну сторінку, вхід, форми та інші критичні функції. Після цього очистьте кеш, щоб відвідувачі отримували актуальну версію файлів.
6. Звірте файли ядра. Команда wp core verify-checksums порівнює їх із контрольними сумами WordPress.org без завантаження самого WordPress. Невідповідність потребує перевірки, але сама команда не сканує базу даних, wp-content або завантажені файли.

Що перевірити після періоду ризику

Якщо сайт залишався на вразливій версії, одного патча недостатньо, щоб довести відсутність попереднього злому. Перегляньте журнали вебсервера та захисного плагіна на незвичні пакетні запити до REST API, перевірте список адміністраторів, неочікувані плагіни й теми, а також змінені або сторонні PHP-файли. Публічного універсального списку індикаторів для кожної атаки немає, тому відсутність одного конкретного запиту не є доказом чистоти.

Якщо є підозрілі зміни, збережіть знімок і журнали перед очищенням, зверніться до хостингу або фахівця з реагування, а після локалізації інциденту змініть паролі WordPress, хостингу, SFTP і бази даних та оновіть секретні ключі WordPress. Встановлення 7.0.2, 6.9.5 або 6.8.6 закриває ці вектори на майбутнє, але не видаляє вже створений бекдор.