Масштаб проблемы
Уязвимость затрагивает огромный пласт инфраструктуры, а именно все версии PHP, начиная с 5.4. Это практически всё, что разворачивалось и администрировалось последние 10–12 лет. Поскольку PHP обеспечивает работу около 70% всего современного веба, под прицелом оказались миллионы сайтов на WordPress, Битрикс, OpenCart, Drupal, Joomla, Magento, а также самописные CRM и личные кабинеты.
Техническая суть уязвимостей
Обе проблемы локализованы в механизме обработки фатальных ошибок и экстренного завершения работы PHP (например, при достижении memory_limit), когда интерпретатор не успевает корректно очистить за собой структуры данных в оперативной памяти.
• CVE-2026-109618 (Разрушение памяти при сбое): Во время разбора входящих multipart-данных процесс аварийно прерывается и выходит через функцию longjmp(). Внутренние структуры данных остаются недоформированными. На этапе закрытия запроса процедура очистки ошибочно принимает этот «мусор» за валидные живые данные. Так как часть этого мусора формируется и контролируется атакующим через тело HTTP-запроса, это позволяет перехватить контроль над выполнением.
• CVE-2026-109619 (Use-After-Free): После возникновения фатальной ошибки глобальные структуры процесса-воркера продолжают ссылаться на освобожденный участок памяти, который операционная система уже выделила под обработку следующего HTTP-запроса. Это открывает путь к исполнению кода через устаревшие указатели, и приводит к утечке конфиденциальной информации — в памяти воркера могут остаться сессии и токены предыдущих пользователей.
Сложность эксплуатации и роль ИИ
На первый взгляд, атака кажется труднореализуемой: хакеру необходимо отправить два последовательных запроса строго в один и тот же рабочий процесс (воркер) и ювелирно подогнать данные под текущую раскладку памяти (Heap Layout). Баги сидели в коде больше десяти лет, и раньше их не превращали в стабильный эксплойт, так как подгонка под память была адским ручным трудом.
Но теперь в дело вступили нейросети. Передовые модели сжимают эту работу с месяцев до одной недели. В результате информация утекла еще до официального релиза, а видео с рабочим эксплойтом мгновенно разошлось по сети. В итоге «маловероятный» сценарий стал стопроцентным и это исключительно вопрос количества автоматических попыток и плотности запросов. Исследователи из Wiz Research и Sansec продемонстрировали стабильно работающие эксплойты против чистых контейнеров с WordPress, Joomla, Drupal и Magento. Компании Cloudflare и watchTowr зафиксировали первые реальные атаки в уже в день публикации патча.
Кто находится под ударом?
Любая серверная среда, которая принимает HTTP-трафик и исполняет PHP-код:
• PHP-FPM, php-cgi, FrankenPHP, LiteSpeed.
• Apache с модулем mod_php — наиболее критичный вариант. В такой конфигурации эксплойт срабатывает на самом раннем этапе, еще до того, как начнет выполняться защитная логика или код самого веб-приложения.
Что делать прямо сейчас?
Обновить PHP
Обновите интерпретатор до последних актуальных версий патча в зависимости от вашей ветки: 8.2.35, 8.3.36, 8.4.27 или 8.5.12. Плагины и темы сайтов трогать не нужно — дыра находится не в них.
Перезапустить воркеры (это часто пропускают!) Просто обновить пакеты в системе недостаточно. Устаревшее уязвимое состояние продолжает жить в активных процессах. Обязательно перезапустите сервисы (systemctl restart php-fpm или Apache) или пересоберите Docker-контейнеры, чтобы очистить оперативную память.
Что делать с версиями 8.1 и старше? Пока официальных патчей для них нет. У вас есть три пути: использовать бэкпорты от вендора вашего дистрибутива ОС, применить исходные бэкпорты от команды PHP для ручной сборки, либо полностью переехать на поддерживаемую ветку. Последний вариант самый правильный, но за один вечер, как правило, его не реализовать.
Временные меры защиты Если вы до сих пор не пропатчились и сервер смотрит в интернет, безопаснее временно снять его с публичного доступа. Также обязательно отключите уязвимую опцию в файле php.ini, которая практически никому не нужна, но закрывает один из подтвержденных векторов атаки: session.upload_progress.enabled = Off
Проверить логи и WAF Крупные WAF-сервисы (Cloudflare, Akamai) уже разослали защитные правила. Это дает временную фору, но не заменяет сам патч. Пока еще никакая конфигурация сервера не закрывает дыру целиком — только обновление гарантирует безопасность, это кстати, официальная позиция команды PHP. После обновления изучите логи: ищите срабатывания memory_limit на multipart-запросах, аномально большие значения PHPSESSID и падения процессов-воркеров без видимой причины.
Критическая оценка 9.2 не прощает медлительности. Автоматизированные сканеры начнут прочесывать сеть в течение ближайших дней.