PHP взломали! Обороняемся

PHP2Shell: дыра в самом языке, из-за которой весь веб на время занервничал

21 октября команда PHP выпустила внеочередные исправления — событие само по себе редкое. Повод достойный: две критические уязвимости в ядре языка, CVE-2026-109618 и CVE-2026-109619, по 9.2 балла из 10. Исследователи назвали их PHP2Shell — «из PHP в шелл». Дыры позволяют удалённо выполнить код на сервере без логина, без пароля и без уязвимостей в вашем коде.

Что случилось

Обе уязвимости — в самом интерпретаторе PHP, а не в приложениях. Сломан механизм обработки ошибок: когда запрос падает — например, из-за нехватки памяти — PHP не всегда корректно убирает за собой.

Первая (109618): при исчерпании memory_limit во время разбора входящих данных PHP выпадает из контекста через longjmp(), оставляя внутренние структуры недоинициализированными. Процедура завершения запроса затем принимает этот мусор за живые данные. Мусор частично контролирует атакующий.

Вторая (109619): после фатальной ошибки глобальные структуры воркера продолжают указывать на память, которая уже освобождена и отдана следующему запросу. Классический use-after-free между запросами — плюс бонусом утечка памяти процесса, где лежат чужие сессии, токены и ключи.

Рабочая цепочка эксплойта требует, чтобы оба запроса попали в один и тот же воркер, и точность подстройки под раскладку памяти — но это вопрос попыток, а не принципиальная защита.

Масштаб

PHP работает примерно на трёх четвертях веба. Затронуты все версии, начиная с 5.4 — то есть за последнее десятилетие не выпущено ни одной неуязвимой ветки. Уязвим любой сервер, который исполняет PHP и принимает HTTP-запросы: PHP-FPM, Apache mod_php (самый рискованный режим — эксплойт срабатывает до запуска кода приложения), php-cgi, FrankenPHP, LiteSpeed. Wiz Research показала готовый эксплойт против свежих контейнеров WordPress, Drupal и Joomla. Sansec подтвердила RCE на Magento и ещё десятке приложений. Даже страница «Hello World» на уязвимой версии — мишень.

Отдельный тревожный сюжет: дефекты сидели в коде больше десяти лет, но превратить их в стабильный эксплойт раньше мешала сложность подгонки под конкретную раскладку памяти. Фронтирные ИИ-модели свели эту работу от месяцев труда элитной команды к неделе усилий одного исследователя. Порог входа в разработку таких атак серьёзно просел.

Информация утекла до официального релиза, видео с работающим эксплойтом разошлось по сети, и Cloudflare с watchTowr зафиксировали первые атаки ещё в день публикации патчей.

Что делать тем, у кого сайт на PHP

Хорошая новость: чинится всё одним действием.

1. Обновить PHP до 8.2.35, 8.3.36, 8.4.27 или 8.5.12 — в зависимости от ветки. Пакетным менеджером дистрибутива или пересборкой docker-образа. Плагины и темы трогать не нужно — дыра не в них.

2. Перезапустить воркеры (php-fpm или Apache) — устаревшее состояние живёт в процессах, просто обновить пакеты недостаточно.

3. Если версия 8.1 или старше — официальных патчей нет: либо бэкпорт от вендора дистрибутива, либо минимальные исходные бэкпорты от команды PHP, либо, что правильнее в перспективе, переезд на поддерживаемую ветку.

4. Пока сервер не пропатчен, а он доступен извне — самое простое честное решение снять его с публичного доступа. Заодно стоит отключить в php.ini опцию session.upload_progress.enabled=0 — она закрывает один из подтверждённых векторов и почти никому не нужна.

5. После обновления проверить логи на следы неудачных попыток: ошибки memory_limit на multipart-запросах, подозрительно большие куки PHPSESSID, необъяснимые падения воркеров. WAF (Cloudflare, Akamai) уже разослал правила — они дают фору, но не заменяют патч.

Ни одна конфигурация не закрывает дыру полностью — обновление единственная надёжная защита, это официально слова команды PHP.

Источники

- Адвизори PHP: CVE-2026-109618 — github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w

- Адвизори PHP: CVE-2026-109619 — github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp