21 октября проект PHP выпустил корректирующие сборки во всех поддерживаемых ветках. Они устраняют две критические уязвимости, позволявшие неаутентифицированному злоумышленнику выполнить код на сервере. Первая срабатывает при повреждении памяти, когда запрос достигает лимита памяти в неудачный момент. Вторая возникает из-за обращения к памяти предыдущего запроса после фатальной ошибки. В связке Apache с mod_php атака проходила до запуска кода приложения, для PHP-FPM удалённое выполнение кода подтвердили через прикладные сценарии.
Обе проблемы лежат в управлении памятью и обработке ошибок. Эти механизмы затрагивает почти каждый запрос, поэтому исправление грозило нарушением обратной совместимости, падением производительности и правками в сторонних расширениях. Признаки первой уязвимости заметили ещё в 2024 году, во время первого за годы внешнего аудита проекта. Аудит организовали на средства Sovereign Tech Agency, работы выполняла компания Quarkslab. Тогда атаку описали только теоретически: рабочих методов эксплуатации не нашли. Вопрос уступил место более очевидным дефектам и на два года выпал из приоритетов.
Задержку усилил организационный фактор. Команда безопасности PHP работала на основе консенсуса и месяцами не могла выбрать между конкурирующими вариантами исправления. В отчёте PHP Foundation названы две причины простоя: процедура принятия решений и нехватка инженеров с глубоким знанием движка. С августа 2026 года ситуация сдвинулась. Рабочие методы эксплуатации независимо друг от друга подтвердили исследователи из Calif, Wiz и OpenAI, после чего решения стали принимать большинством голосов.
Координированное раскрытие сорвалось за двое суток до релиза. 20 октября идентификаторы уязвимостей разошлись по форумам и соцсетям вместе с неверным временем выпуска и оценкой опасности 10,0 при фактических 9,2. Технические детали не утекли, но проект перенёс публикацию на сутки раньше и сократил срок предупреждения для дистрибутивов. Затем Calif по ошибке выложила видео с демонстрацией прототипа эксплойта (вредоносного кода, эксплуатирующего уязвимость). За шесть часов до релиза Chainguard опубликовал готовые сборки с исправлением в обход эмбарго.
Даже в этих условиях проект не зафиксировал на момент выпуска ни одного работоспособного эксплойта. При этом поток сообщений об уязвимостях растёт: с 1 июля команда опубликовала пятнадцать уведомлений и разобрала больше сотни обращений, которые оказались дублями, ошибками или невоспроизводимыми случаями. Инструменты на базе ИИ ускоряют поиск дефектов и у защитников, и у злоумышленников. Решение о способе исправления и проверку патча по-прежнему выполняет человек.
Последствия затрагивают всех, кто держит веб-сервисы на PHP: государственные порталы, интернет-магазины, банки, медиа. Обновление требует внимания и от облачных провайдеров, и от поставщиков долгосрочной поддержки. Для заказчиков хостинга срок установки часто делят между собой владелец приложения и провайдер. Регуляторный аспект неочевиден, но значим. Во многих отраслях сроки устранения критических уязвимостей закреплены внутренними регламентами, а срок раскрытия зависит от добросовестности каждого участника. Один поставщик, нарушивший эмбарго, сокращает это окно для всех остальных.
Выпуск закрывает уязвимости, но фиксирует более общую тенденцию. Дефекты находят быстрее, чем небольшая группа сопровождающих успевает их разобрать, взвесить совместимость и согласовать дату. Отчёт оставляет открытым вопрос устойчивости: работа по-прежнему опирается на нескольких разработчиков и внешнее финансирование.
