PHP2Shell: исследователи с помощью ИИ нашли две критические уязвимости в PHP, а атаки начались через считаные дни

Что исправили

Уязвимости получили номера CVE-2026-109618 и CVE-2026-109619; обе оценены в 9,2 балла по шкале CVSS v4.0. Первая связана с тем, как PHP обрабатывает нехватку памяти посреди запроса; из-за второй внутренние данные продолжают ссылаться на память, которую уже освободил предыдущий запрос. Согласно бюллетеню проекта PHP, под угрозой все установки PHP, обслуживающие веб-запросы, включая PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Выше всего проект оценивает риск для mod_php: там запрос без авторизации может запустить атаку ещё до того, как выполнится код приложения.

По словам проекта PHP, полностью проблему решает только обновление; временные настройки снижают риск отдельных сценариев атаки, но «не делают установку безопасной». PHP 8.1 и более старые версии официальных обновлений больше не получают. Из-за серьёзности уязвимостей команда безопасности PHP выпустила минимальные исправления исходного кода для версий 7.4, 8.0 и 8.1 для тех, кто собирает PHP самостоятельно, а некоторые дистрибутивы Linux и поставщики долгосрочной поддержки выпускают собственные исправленные пакеты. 23 октября проект добавил ещё один бюллетень с меньшим уровнем риска (CVE-2026-115560) — о маловероятном пути атаки при необычной конфигурации; исправление выйдет в следующем плановом выпуске. До тех пор проект рекомендует сохранять одну из временных мер защиты, поэтому уточните у хостинг-провайдера, применил ли он её.

При чём здесь ИИ

По данным OpenAI, Calif обнаружила критическую уязвимость с помощью GPT-5.6 Sol в рамках инициативы OpenAI Patch the Planet, а Wiz независимо нашла обе уязвимости и сообщила о них. OpenAI говорит, что затем около двух месяцев помогала координировать работу с разработчиками PHP, Wiz, Cloudflare и американскими госведомствами, включая CISA.

Сама проблема не новая. PHP Foundation сообщает, что разработчик, работающий с фондом по контракту, заметил первые признаки ошибки с памятью ещё в 2024 году, но практического способа атаки тогда не знали, и работа над исправлением месяцами то останавливалась, то начиналась заново. Фонд называет эту задержку «структурным провалом». Отчёт Calif от 11 августа показал безусловное удалённое выполнение кода с той же первопричиной, затем последовали сообщения от Wiz и OpenAI.

Сама Calif не преувеличивает роль ИИ. Как пишет TechCrunch, по словам Calif, ИИ помогал в работе над эксплойтом, но в основном она опиралась на уже имевшиеся у исследователей знания о PHP. В её разборе сказано: «Ни одна модель не способна просто так найти „все баги“ простыми запросами. По крайней мере пока».

Тем не менее поток сообщений растёт. PHP Foundation сообщает, что с 1 июля команда безопасности опубликовала 15 CVE и разобрала более 100 сообщений, которые оказались недействительными, дубликатами или не воспроизводились. OpenAI ожидает, что подобных находок «в ближайшие месяцы станет резко больше», и выделила 1 млрд долларов на субсидированный доступ к своим инструментам безопасности Daybreak для организаций с ограниченными ресурсами, которые защищают жизненно важные сервисы.

Злоумышленники не стали ждать исправлений

Скоординированный выпуск прошёл не по плану. По словам PHP Foundation, номера CVE начали расходиться в сети 20 октября с неверной оценкой опасности, поэтому выпуск перенесли на день раньше — на 14:00 UTC 21 октября. Фонд также сообщает, что поставщик ПО Chainguard опубликовал исправленные образы более чем за шесть часов до согласованного времени, и изучить исправление заранее мог любой.

Amazon Threat Intelligence сообщила о попытке эксплуатации против своих датчиков-ловушек, датированной 17 октября, то есть за четыре дня до раскрытия; запрос шёл из анонимизирующей сети. В Amazon говорят, что неясно, как атакующий получил сведения, и неясно, сработали бы на реальных системах попытки, зафиксированные до выпуска исправлений. К 21 октября компания описывала «многочисленные попытки эксплуатации в реальных атаках». TechCrunch 24 октября сообщил, что Palo Alto Networks и Trail of Bits подтвердили взломы и активность после проникновения, связанные с этими уязвимостями.

Вывод Amazon касается каждого владельца сервера: для критических уязвимостей в системах, доступных из интернета, сроки установки исправлений нужно считать в часах, потому что анализ с помощью ИИ удешевляет превращение опубликованного исправления в рабочий эксплойт. Компания советует проверять системы начиная с 17 октября, а не с даты раскрытия.

Что это значит для сайта малого бизнеса

PHP используется повсюду. По данным W3Techs на 26 октября, он работает на 69,2% сайтов, чей серверный язык удаётся определить; на нём же работают WordPress, Drupal и Joomla. Уязвимость находится в самом PHP, поэтому обновление плагинов или тем WordPress её не закрывает: исправленную версию PHP должен установить тот, кто обслуживает сервер. На управляемом хостинге это обычно хостинг-провайдер, и у него можно запросить письменное подтверждение того, на какой версии PHP теперь работает сайт.

Те же данные W3Techs показывают, что примерно треть сайтов на PHP до сих пор работает на версии 7 или старше, которую проект PHP больше не поддерживает. Версии 8.0 и 8.1 тоже не поддерживаются, а для 8.2, согласно php.net, поддержка заканчивается 31 декабря 2026 года. Для сайтов на неподдерживаемых версиях вопрос в том, кто предоставит исправленную сборку или как быстро сайт можно перевести на поддерживаемую версию.

Британский Национальный центр кибербезопасности (NCSC) призывает организации найти все системы с PHP, начать с доступных из интернета, обновить их и рассмотреть отключение системы, если её не удаётся быстро обновить или защитить. Центр также советует проверить системы на признаки взлома и следить за обновлениями устройств и сервисов со встроенным PHP. TechCrunch отмечает, что PHP работает и внутри некоторых роутеров, сетевых хранилищ, межсетевых экранов и VPN.