Власникам сайтів на WordPress версій 6.9.0–6.9.4 або 7.0.0–7.0.1 потрібно оновитися негайно. Команда безпеки WordPress виправила CVE-2026-63030, також відому як wp2shell, — критичну вразливість віддаленого виконання коду без автентифікації в ядрі WordPress. Вразливий шлях доступний анонімному зловмиснику у стандартній інсталяції; плагін або чинний обліковий запис не потрібні.[1]
Виправлення містять WordPress 6.9.5 і 7.0.2. WordPress увімкнув примусові автоматичні оновлення для вразливих сайтів, однак адміністратору варто перевірити фактично встановлену версію, а не покладатися лише на фонове оновлення.[2]
Які версії WordPress уразливі?
| Встановлена версія | Ризик і дія |
|---|---|
| 6.9.0–6.9.4 | Уразливі до wp2shell. Оновіть до 6.9.5 або новішого підтримуваного випуску. |
| 7.0.0–7.0.1 | Уразливі до wp2shell. Оновіть до 7.0.2 або новішої версії. |
| 6.8.5 або старіше | Не уражені CVE-2026-63030. Інші виправлення безпеки все одно можуть бути потрібні, тому використовуйте підтримувану гілку. |
| 7.1 beta | Використовуйте 7.1 Beta 2 або новішу збірку, якщо сайт навмисно тестує beta-гілку. |
Розмежування версій важливе. Той самий липневий security-реліз виправляє окрему SQL-ін’єкцію у старіших гілках, але сам ланцюжок wp2shell з’явився у WordPress 6.9. Не варто називати кожен старіший сайт WordPress уразливим саме до цієї CVE.
Що може зробити wp2shell
WordPress описує проблему як плутанину маршрутів пакетних запитів REST API разом із SQL-ін’єкцією, що призводить до віддаленого виконання коду. Критичний advisory називає уражені версії, але не публікує експлойт.[1] Searchlight Cyber, чий дослідник Адам Кюс повідомив про помилку, зазначає: атака не має передумов і працює проти стандартної інсталяції WordPress без плагінів.[3]
Віддалене виконання коду означає, що успішний нападник може запускати серверний код із правами вебпроцесу. Практичними наслідками можуть бути змінені сторінки, шкідливі редиректи, викрадені секрети конфігурації, новий адміністратор або постійний бекдор. Це можливі наслідки RCE, а не опубліковані індикатори саме wp2shell. На момент публікації первинні джерела не розкривали технічних деталей і не повідомляли про підтверджену експлуатацію у реальних атаках.
Як перевірити встановлену версію
- Відкрийте Dashboard → Updates і перевірте версію WordPress. Якщо сайт усе ще показує 6.9.0–6.9.4 або 7.0.0–7.0.1, запустіть оновлення ядра.
- На хостингу з WP-CLI виконайте
wp core versionу корені WordPress і переконайтеся, що результат — 6.9.5, 7.0.2 або новіше. - Окремо перевірте production, staging, забуті піддомени та клієнтські інсталяції. Успішне оновлення одного сайту не доводить, що інші теж захищені.
- Після оновлення відкрийте публічну частину й адмінпанель, протестуйте важливі форми або checkout і переконайтеся, що не залишився maintenance-файл чи PHP-помилка.
Якщо негайне оновлення неможливе, Searchlight Cyber радить тимчасово заблокувати анонімний доступ до /wp-json/batch/v1 і ?rest_route=/batch/v1 на WAF. Це лише аварійний міст до патча: блокування batch API може зламати легітимні інтеграції й не замінює оновлення ядра.[3]
Що перевірити, якщо сайт могли зламати
У первинному розкритті немає специфічних індикаторів wp2shell, тому не вигадуйте назву файла або готовий список IP. Перед очищенням збережіть журнали вебсервера, WAF, хостингу та автентифікації, а потім перевірте зміни від часу встановлення вразливої версії.
- Зіставте адміністраторів WordPress та application passwords із затвердженим списком.
- Перегляньте нещодавно змінені файли ядра, активні теми, плагіни,
mu-plugins, cron-завдання та несподівані PHP-файли у доступних для запису каталогах. - Шукайте незрозумілі редиректи, вставлений JavaScript, невідомі вихідні з’єднання або зміни у
wp-config.phpі серверних правилах. - Якщо компрометація ймовірна, відновіть перевірену чисту резервну копію, змініть паролі бази даних, хостингу й адміністраторів, оновіть salts, відкличте сесії та встановіть патч до повернення сайту в роботу.
Оновлення ядра закриває вразливий маршрут, але не видаляє бекдор, встановлений до патча. Наш матеріал про Steam C2-бекдор у WordPress пояснює, чому після інциденту потрібно перевіряти теми, плагіни, uploads і механізми закріплення, а не лише видалити видимого адміністратора.
Що робити власникам сайтів зараз
- Створіть резервну копію бази даних і файлів звичним перевіреним способом.
- Оновіть WordPress Core до 6.9.5, 7.0.2 або новішого підтримуваного випуску.
- Перевірте версію на кожній інсталяції та працездатність публічного сайту.
- Приберіть тимчасове WAF-правило лише після підтвердження патча й тестування потрібних інтеграцій.
- Переходьте до incident response, якщо журнали, користувачі, файли або редиректи вказують на зміни до встановлення патча.
References
- WordPress. “REST API batch-route confusion and SQL injection issue leading to Remote Code Execution.” GitHub Security Advisory GHSA-ff9f-jf42-662q, опубліковано 17 липня 2026 року, переглянуто 17 липня 2026 року. https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-ff9f-jf42-662q
- WordPress.org. “Version 7.0.2.” WordPress Documentation, опубліковано й оновлено 17 липня 2026 року, переглянуто 17 липня 2026 року. https://wordpress.org/documentation/wordpress-version/version-7-0-2/
- Adam Kues. “wp2shell: Pre Authentication RCE in WordPress Core.” Searchlight Cyber, опубліковано 17 липня 2026 року, переглянуто 17 липня 2026 року. https://slcyber.io/research-center/wp2shell-pre-authentication-rce-in-wordpress-core/
