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