У самому серці найпопулярнішої системи керування вмістом WordPress виявлено критичну вразливість під кодовою назвою wp2shell, яка дозволяє неавторизованим зловмисникам виконувати довільний код на цільовому сервері. Ця проблема є надзвичайно небезпечною, оскільки вона локалізована безпосередньо в ядрі CMS (WordPress Core). Це означає, що для успішної атаки зловмисникам не потрібні жодні сторонні плагіни чи теми — під загрозою опиняється навіть чисте, базове встановлення системи (bare install). Вразливість охоплює всі сайти, що працюють під керуванням версій 6.9 та 7.0, до моменту встановлення виправлень.

Критична вразливість wp2shell у ядрі WordPress дозволяє запуск коду

Останні оновлення аналітичних звітів підтверджують, що виявленим недолікам безпеки вже присвоєно офіційні ідентифікатори CVE, а повний технічний механізм експлуатації оприлюднено у відкритому доступі. Атака запускається за допомогою одного анонімного HTTP-запиту, що значно спрощує її масштабування з боку кіберзлочинців. Окрім того, дослідники виявили зв'язок між можливістю виконання коду та станом персистентного кешування об'єктів (persistent-object-cache). Наявність публічного робочого прототипу експлуату (Proof-of-Concept, PoC) робить цю загрозу актуальною «тут і зараз».

Технічна суть проблеми полягає в тому, як саме ядро WordPress обробляє анонімні запити у поєднанні з підсистемою кешування. У великих проектах для зниження навантаження на базу даних часто використовують персистентний кеш (наприклад, Redis або Memcached) через механізм persistent-object-cache. Зловмисник може надіслати спеціально сформований запит, який маніпулює ключами кешу або даними під час їх серіалізації. В результаті ядро системи завантажує шкідливий об'єкт або виконує несанкціоновану десеріалізацію, що зрештою призводить до виконання PHP-коду на боці сервера.

Оскільки WordPress забезпечує роботу понад 40% усіх вебсайтів у світі (зокрема тисяч українських державних ресурсів, медіа та бізнес-порталів), наслідки масової експлуатації wp2shell можуть бути катастрофічними. Автоматизовані сканери та ботнети зазвичай починають масове сканування мережі протягом кількох годин після публікації PoC. Це означає, що будь-який непатчений ресурс автоматично стає легкою здобиччю для шкідливого програмного забезпечення, шифрувальників або вебшеллів, які використовуються для подальшого просування вглиб корпоративної інфраструктури.

Ситуація ускладнюється тим, що розробники тривалий час намагалися локалізувати проблему без залучення зайвої уваги, проте після присвоєння CVE деталі ланцюжка атаки стали відомі широкому загалу. Традиційні засоби захисту, такі як базові брандмауери вебдодатків (WAF), не завжди здатні ефективно розпізнати цей вектор атаки без специфічних сигнатур, оскільки шкідливий запит може виглядати як легітимне звернення до стандартних функцій ядра WordPress. Тому єдиним надійним методом захисту залишається своєчасне оновлення самого коду CMS.

З точки зору проведення тестів на проникнення (пентесту), ця вразливість демонструє, чому не можна ігнорувати безпеку навіть тих систем, які здаються «простими візитками» чи блогами на периферії інфраструктури. Дуже часто компрометація корпоративного блогу на WordPress стає першим кроком для проникнення у внутрішню мережу компанії, де зловмисники можуть викрасти чутливі дані або заблокувати критичні сервіси.

Що це означає на практиці

  • Негайне оновлення WordPress: Перевірте поточну версію вашої системи. Якщо ви використовуєте гілки 6.9 або 7.0, негайно встановіть останні доступні безпечні патчі. Якщо автоматичні оновлення вимкнені у файлі wp-config.php, проведіть оновлення вручну через консоль адміністратора або за допомогою інструменту WP-CLI.
  • Аудит конфігурації об'єктного кешування: Проаналізуйте використання персистентного кешу на сервері. Перевірте файл wp-content/object-cache.php та переконайтеся, що ваші сервери Redis або Memcached не мають публічного доступу з інтернету та захищені надійними паролями, а права доступу до конфігураційних файлів обмежені.
  • Налаштування правил WAF: Якщо ви використовуєте Cloudflare, ModSecurity чи інші рішення класу Web Application Firewall, увімкніть специфічні правила для захисту WordPress Core та блокування запитів із підозрілими серіалізованими даними. Це допоможе стримати першу хвилю автоматизованих сканувань, поки триває процес оновлення.
  • Контроль прав доступу вебсервера: Переконайтеся, що процес вебсервера (Nginx або Apache) та інтерпретатор PHP-FPM працюють з обмеженими привілеями (наприклад, від імені користувача www-data) та не мають прав на запис у критичні директорії ядра WordPress, такі як wp-admin та wp-includes. Це суттєво ускладнить зловмиснику закріплення в системі навіть у разі спроби компрометації.
  • Аналіз логів на ознаки зламу: Перевірте логи доступу вебсервера за останні дні. Шукайте нетипові POST-запити від анонімних користувачів, які призвели до відповідей із кодом 200, а також перевірте цілісність файлової системи за допомогою утиліти wp core verify-checksums, щоб переконатися, що файли ядра не були модифіковані.