PHP2Shell: як один запит став RCE і як це виправити

PHP2Shell — прізвисько двох критичних вразливостей середовища виконання PHP, CVE-2026-109618 і CVE-2026-109619, розкритих у жовтні 2026 року. Разом вони дають змогу виконувати команди на вебсервері одним зіпсованим запитом і без жодного входу. Експлуатація почалася 17 жовтня, за чотири дні до того, як PHP випустив виправлення 21 жовтня.

У цьому дописі ми пройдемо ланцюжок атаки, реагування, яке справді її зупиняє, і прибирання, якого саме лише оновлення ніколи не робить. Усе тут відповідає нашій безкоштовній вправі PHP2Shell RCE, де ви граєте і за зловмисника, і за чергового інженера.

PHP2Shell — пара вразливостей віддаленого виконання коду (RCE) без автентифікації в самому середовищі виконання PHP, а не у фреймворку чи плагіні. Спеціально сформований запит порушує те, як PHP готує й звільняє дані кожного запиту, тож середовище виконання повторно використовує пам’ять незавершеного запиту. Цього досить, щоб перехопити виконання й запускати команди зловмисника від імені користувача вебсервера.

Оскільки вада лежить нижче за застосунок, ціллю стає будь-яка адреса .php на доступному сервері. Немає облікового запису для фішингу, форми завантаження для зловживання чи вразливого плагіна для пошуку.

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

1. Розвідка. Звичайний GET повертає заголовки на кшталт Server: Apache/2.4.58 і X-Powered-By: PHP/8.4.26. Виправлена збірка гілки 8.4 — 8.4.27, тож зловмисник знає, що хост відкритий.
2. Постріл. Один зіпсований запит до будь-якої сторінки PHP повертає результат команди, яку обрав зловмисник.
3. Здобич. Той самий запит читає пароль до бази даних із конфігурації застосунку й рахує рядки таблиці клієнтів, готуючи їх до викрадення.
4. Закріплення. Невеликий вебшел з’являється за безневинним шляхом, наприклад у теці медіакешу, тож доступ переживає перезапуск і навіть пізніший патч.

Apache з mod_php — найгірший випадок. Вразлива обробка запиту відбувається в процесі вебсервера ще до коду застосунку, тож ваш застосунок не має шансу відмовити.

Ні. Сигнатури WAF варто ввімкнути, але правило блокує лише ті форми запиту, які знає. Зловмисники змінюють навантаження, доки одне не пройде.

Сприймайте WAF як час, який ви купуєте для оновлення. Вада в середовищі виконання, тож закриває її лише виправлене середовище виконання.

Виправлення має дві частини, і команди під тиском регулярно пропускають другу.

• Оновіть середовище виконання до виправленої збірки (8.4.27 у гілці 8.4 або пакет вашого дистрибутива з бекпортом).
• Перезапустіть службу, яка тримає PHP у пам’яті: Apache для mod_php або PHP-FPM за Nginx. Доки вона не перезапуститься, кожен запит обслуговує стара вразлива збірка.

Сервер, на якому пакет установили, але не перезапустили, показує в менеджері пакетів заспокійливу версію й лишається вразливим. Після перезапуску перевірте версію, яку справді повідомляє вебсервер, а тоді повторіть відомий шкідливий запит і переконайтеся, що він більше не спрацьовує. Наша вправа «Оновлення ОС та основи патчів» відпрацьовує ту саму звичку «встановлено ще не означає запущено» для робочих станцій.

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

• Шукайте підкинуті файли. Перевірте файли PHP, яких ваше розгортання ніколи не постачало, особливо в теках із правом запису: завантаження, кеші, тимчасові каталоги. Видаліть вебшел.
• Замініть кожен секрет, який міг прочитати сервер. Паролі до баз даних, ключі API та хмарні облікові дані в конфігураційних файлах чи змінних середовища скомпрометовані.
• Передайте можливе розкриття даних. Якщо зловмисник міг дістатися персональних даних, негайно передайте це команді із захисту даних. За GDPR 72-годинний строк повідомлення починається з моменту, коли ви дізналися про порушення, а не коли закінчилося розслідування.

Швидке повідомлення важить не менше, ніж технічне виправлення. Наша вправа «Основи повідомлення про інциденти» у каталозі з обізнаності з безпеки пояснює, кому повідомляти й що фіксувати.

Публічна вітрина рідко буває єдиною копією. Вразливість нульового дня в середовищі виконання відкриває всі встановлення одночасно, зокрема ті, яких не торкається одне оновлення пакета.

• Контейнери, зібрані з базового образу, де зафіксовано старий PHP. Перезберіть їх з оновленого образу й розгорніть заново: латка в запущеному контейнері зникне після наступного перезапуску.
• Пристрої, панелі керування й продукти постачальників із власним PHP. Тут доводиться чекати оновлення від постачальника.
• Забуті тестові хости, внутрішні інструменти й маркетингові мікросайти.

Це та сама проблема, що й з будь-якими компонентами з відомими вразливостями: неможливо оновити те, чого ви не інвентаризували. Якщо ви збираєте образи контейнерів, вправа «Вразливі базові образи» показує, як старе середовище виконання ховається в шарі, на який ніхто не дивиться.

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

Каталог реальних інцидентів перетворює такі зломи на практичні вправи, поряд із розбором зламу MGM Resorts. Розробники, яким цікавий бік коду, можуть продовжити вправою «Ін’єкція команд», а наш огляд найкращих платформ навчання безпечного кодування порівнює ширший вибір.

Хочете, щоб ваша платформна команда відпрацювала наступну вразливість нульового дня ще до її появи? Напишіть нам, щоб запровадити навчання на основі інцидентів.