php-vulnerability-audit — аудит, оновлення й захист від PHP2Shell
Огляд
21 жовтня 2026 року команда PHP випустила екстрені релізи для двох критичних вразливостей віддаленого виконання коду в самому інтерпретаторі, CVE-2026-109618 і CVE-2026-109619 («PHP2Shell», знайдені Wiz Research). Помилка не в CMS чи плагіні: під ризиком будь-який сайт на вразливому PHP, хоч би яким чистим був його власний код, а зачеплені версії аж до PHP 5.4.
Послуга: знайти, де в інфраструктурі працює вразливий PHP, довести його до виправленої версії (або до безпечного проміжного стану), підтвердити виправлення з боку вебу й перевірити, чи сервер уже не зачепили. Для сайтів на WordPress, OpenCart, Joomla, Laravel і самописному PHP, на VPS, виділеному сервері, шерингу чи в Docker.
Виправлені версії
| Гілка PHP | Виправлена версія (21 жовтня 2026) |
|---|---|
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35 |
| 8.1 і старіші | Оновлень від проєкту PHP немає. Для 7.4, 8.0 і 8.1 є мінімальні бекпорти в сирцях; частина дистрибутивів і LTS-вендорів випускає власне виправлення. Інакше: міграція на підтримувану гілку |
Офіційне повідомлення PHP пряме: повних обхідних заходів немає, безпечний вибір один — оновлення.
Що входить
| Крок | Що робиться |
|---|---|
| Інвентаризація | Кожен сервер, VPS, хостинг-акаунт, Docker-образ і CI-раннер, що обробляє PHP, і який web SAPI він використовує (mod_php, PHP-FPM, CGI, LiteSpeed, FrankenPHP). Advisory оцінює mod_php як найризиковіший, бо експлойт може спрацювати ще до запуску коду застосунку |
| Перевірка версії | Версія, яку реально віддає веб, а не лише php -v у шелі: CLI і web SAPI часто різні збірки. Порівняння з виправленими версіями вище |
| Оновлення | Виправлений реліз; або бекпорт вендора (Ubuntu, Debian, AlmaLinux, CloudLinux, cPanel, Plesk); або міграція на PHP 8.3 / 8.4 з перевіркою сумісності CMS, плагінів і самописного коду спершу на staging-копії |
| Тимчасові заходи | Лише коли оновлення не можна випустити сьогодні, і лише заходи з advisory PHP: session.upload_progress.enabled=0 у php.ini чи пулі FPM (не через ini_set() чи .user.ini), fatal_error_backtraces=0 на PHP 8.5, невеликий post_max_size, memory_limit там, де застосунки не можуть його змінити. Плюс правило WAF чи allow-list IP для критичного сайту. Фіксується як тимчасове |
| Перевірка результату | Перезапуск усіх PHP-воркерів, повторна перевірка версії з боку вебу, smoke-тест сайту та його оформлення замовлення чи форм |
| Перевірка на компрометацію | Логи на ознаки, опубліковані Wiz: multipart-запити з наступними помилками memory limit, повторні HTTP 500, завеликі або некоректні cookie PHPSESSID, «перезапуски» PHP-воркерів. Порівняння файлів із чистими ядрами CMS. Якщо експозиція ймовірна: ротація паролів БД, API-ключів, токенів і сертифікатів, адже одна з вразливостей може розкривати пам’ять воркера |
У логах застосунку може бути майже нічого, бо вразливості лежать нижче рівня застосунку. Тому чистий лог не вважається доказом чистого сервера: перевірка — це набір дій, а не гарантія.
Як це відбувається
- Інвентар і перевірка версій. Список усіх хостів із версією PHP і SAPI, які вони реально віддають.
- Ризик і план. Хости впорядковані за експозицією; для кожного маршрут: оновлення, бекпорт вендора або міграція.
- Оновлення на staging, потім у проді. Для магазинів і сайтів із самописним кодом оновлення спершу відпрацьовується на копії; перемикання робиться у тихе вікно.
- Перевірка та огляд. Воркери перезапущені, версія повторно перевірена з вебу, логи переглянуті, секрети змінені там, де треба.
- Короткий звіт. Хости, версії до і після, що змінено, що лишилося (наприклад, PHP за межами підтримки, якому потрібна планова міграція).
Якщо сайт уже зламано, лікування описане в site-security-cleanup; якщо перехід на новий сервер чи версію PHP треба зробити без простою, дивіться zero-downtime-migration.
Джерела
Стек
PHP 5.4 – 8.5 · mod_php · PHP-FPM · Apache · Nginx · LiteSpeed · Linux (Ubuntu / Debian / AlmaLinux) · Docker · WordPress · OpenCart · Joomla · Laravel · Cloudflare WAF · ModSecurity · Fail2ban