Две критические уязвимости PHP, объединённые под названием PHP2Shell, вынудили часть операторов временно отключить сайты и сервисы 21 октября. Исправления вышли для поддерживаемых веток PHP 8.2–8.5, но сама авария быстро превратилась в спор о том, можно ли ломать эмбарго на патчи, если признаки атаки уже появились. Для российских команд это вполне прикладной сюжет: PHP может быть спрятан за CMS, контейнером или managed-хостингом — и всё равно оставаться частью внешнего контура.
Как сообщает The New Stack, уязвимости получили идентификаторы CVE-2026-109618 и CVE-2026-109619. Исправленные релизы: PHP 8.2.35, 8.3.36, 8.4.27 и 8.5.12. Пользователям старых веток нужно переходить на поддерживаемую версию либо проверять, выпустил ли дистрибьютор backport. Сам факт, что сайт работает на WordPress, не означает автоматическое обновление: патчить требуется именно PHP в окружении, а не только CMS.
Проблема затрагивает один из самых распространённых серверных языков: PHP используется примерно на 70% сайтов, хотя эта оценка не равна числу уязвимых или скомпрометированных ресурсов. По данным издания, один из дефектов связан с обработкой нехватки памяти: процесс может сохранить ссылки на уже освобождённую память, а следующий запрос — обратиться к ним как к валидным. Такой класс ошибок способен привести к утечке данных или выполнению кода на сервере без аутентификации.
В этой истории особенно неприятно не только техническое содержание CVE. Исследовательская компания Calif обнаружила путь к удалённому выполнению кода 11 августа в рамках инициативы OpenAI Patch the Planet, использовав GPT-5.6 Sol. В тот же день о той же первопричине сообщила OpenAI, а 24 августа свои находки передала Wiz. При этом разработчики PHP видели признаки лежащей в основе проблемы ещё во время аудита 2024 года, но не смогли тогда довести анализ до рабочего сценария удалённого выполнения кода.
Фонд PHP позднее назвал задержку структурным сбоем: варианты исправления конфликтовали с совместимостью, производительностью и сторонними расширениями, а ресурсов и ясного механизма принятия решения не хватило. Это знакомая математика open source: обнаружить странное поведение в C-коде можно давно, но сделать патч, который не ломает миллионы установок, гораздо труднее. ИИ здесь не создал ошибку — он резко сократил время, нужное для сборки цепочки эксплуатации.
Параллельно развалился режим координированного раскрытия. По версии PHP Foundation, 20 октября в публичном поле появились номера CVE, затем случайно опубликовали видео с proof-of-concept. На следующий день Chainguard выложила образы контейнеров с исправлениями более чем за шесть часов до согласованного времени релиза. Гендиректор и сооснователь Chainguard Дэн Лоренц объяснил решение сообщениями о возможной эксплуатации в реальной среде, утечками и тем, что компания самостоятельно воспроизвела проблему с помощью своей тестовой системы и продвинутой ИИ-модели.
Фонд PHP оценил поступок иначе: досрочно опубликованный собранный образ даёт атакующему материал для сравнения исправленного и уязвимого кода, пока другие поставщики ещё не готовы. Однозначного подтверждения успешных атак на реальные системы на момент публикации не было. Amazon Threat Intelligence зафиксировала попытки эксплуатации в honeypot 17 и 21 октября, но не смогла подтвердить, сработали бы они на настоящих развёртываниях. В споре нет комфортного ответа: ранний патч одновременно сокращает окно риска для одних и расширяет его для тех, кто ещё ждёт обновления.
Практический вывод для владельца PHP-инфраструктуры скучен, но именно скучные действия обычно спасают прод: определить все публичные инстансы, проверить версию и vendor advisory, развернуть протестированный патч вне обычного окна обслуживания и посмотреть журналы как минимум с 17 октября. WAF-правила и защитные механизмы хостинга полезны как временный слой, но не заменяют обновление. Отдельно стоит проверить контейнерные базовые образы, CI-шаблоны и забытые административные панели — PHP часто живёт там, где его уже никто не считает частью продукта.
PHP2Shell показывает, что критические уязвимости PHP теперь могут находить быстрее, чем небольшие команды сопровождения успевают оценить и исправить их последствия. Следующий конфликт будет не о том, использовать ли ИИ для поиска багов, а о том, кто оплатит triage, разработку патча и короткое, но безопасное окно эмбарго. Подробную хронологию конфликта и позиции участников приводит .
