Команда PHP 21 октября выпустила исправления двух критических уязвимостей, позволяющих выполнять код на сервере без входа в аккаунт. Одновременно PHP Foundation раскрыла предысторию: первые признаки одной из ошибок обнаружили ещё в 2024 году, но работа над исправлением неоднократно останавливалась. Утром мы писали о предупреждении; теперь известны механизм атаки и исправленные версии.

Обе ошибки находятся в обработке памяти и сбоев внутри самого PHP. В первом случае нехватка памяти могла прервать подготовку внутренних данных запроса, после чего незавершённые структуры обрабатывались как корректные. Во втором — после аварийного завершения запроса оставались ссылки на уже освобождённую память, которыми мог воспользоваться следующий запрос. Для Apache с модулем mod_php разработчики подтвердили атаку, срабатывающую ещё до запуска кода сайта: аккуратно написанное приложение само по себе такую брешь не закрывает.

Исследователи Wiz продемонстрировали выполнение кода без авторизации на установках WordPress, Drupal и Joomla, а отдельно — чтение памяти процесса с паролями, токенами и API-ключами. Это проверенные сценарии атаки, а не число реально взломанных сайтов. Условия различаются между версиями и конфигурациями PHP; перенос работающей атаки на другую установку может требовать адаптации.

По объяснению PHP Foundation, в 2024 году практического пути к удалённому выполнению кода ещё не нашли. Предложенные исправления грозили нарушить совместимость, создать новые отказы в обслуживании или потребовать изменений сторонних расширений. Команда не могла выбрать компромисс и испытывала нехватку специалистов — фонд прямо признал задержку структурным сбоем. После демонстрации удалённого выполнения кода Calif и независимого сообщения OpenAI 11 августа 2026 года исправление стало главным приоритетом. В работе использовались ИИ-инструменты, однако решения и правки, подчёркивает фонд, оставались за людьми.

Исправления вышли в PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Команда PHP относит к группе риска все установки, обслуживающие веб-запросы, включая PHP-FPM, mod_php, php-cgi, FrankenPHP и LiteSpeed; наиболее высоким она считает риск для mod_php. Временные ограничения блокируют лишь отдельные пути атаки — полноценным решением разработчики называют обновление. Для старых веток отдельно нужно проверять наличие перенесённого исправления у поставщика: номер устаревшей основной версии сам по себе не показывает, получил ли пакет защиту.