Спустя пять дней после раскрытия двух критических уязвимостей PHP2Shell 93,6% систем из наблюдаемой выборки всё ещё не были исправлены. Для компаний, которые держат на PHP публичные сайты, личные кабинеты и API, это уже не теоретический CVE в бэклоге: атаки зафиксированы в реальной сети, а часть старых инсталляций вообще не получит штатного патча.
Речь идёт о CVE-2026-109618 и CVE-2026-109619 с оценкой 9,2 по шкале CVSS. Их объединяют под названием PHP2Shell: ошибки в самом рантайме PHP могут позволить удалённо выполнить код на сервере или извлечь чувствительные данные из памяти процесса. Как сообщает The New Stack, исследователи наблюдают атаки, а темп установки обновлений заметно отстаёт от масштаба угрозы.
По данным компании OX Security на 26 октября, через пять дней после публикации информации об уязвимостях доля доступных извне систем без исправления почти не изменилась и составляла 93,6%. Исследователь Moshe Siman Tov Bustan сформулировал проблему жёстко: тревога вокруг CVE не превратилась в массовое обновление. Это важное различие. Заголовки и экстренные созвоны сами по себе не уменьшают поверхность атаки; её уменьшают только установленный патч, подтверждённая версия пакета и проверка, что обновлённый процесс действительно запущен в продакшене.
Картина по интернет-сканированию тоже выглядит тревожно. Censys насчитал около 11,2 млн публичных PHP-сервисов, которые сообщают о версиях с исправлением, и примерно 32,5 млн сервисов с небезопасными версиями. Ещё у 61,3 млн сервисов — 58% от обнаруженных — версию определить не удалось. Эти цифры нельзя механически читать как число взломанных или уязвимых хостов: Linux-дистрибутивы часто бэкпортируют исправления, не меняя номер версии PHP. Но они хорошо показывают масштаб инвентаризационной проблемы: у многих команд нет надёжного ответа на простой вопрос, какой именно рантайм обслуживает конкретный домен.
Отдельная неприятность — давно снятые с поддержки ветки. В исследовании Flare, охватившем 2,2 млн записей PHP-сервисов, почти три четверти рекламировали ветку, которую PHP-проект уже не поддерживает. Компания Mallory получила похожий результат: около 1,9 млн из 2,6 млн изученных публичных сервисов работали на неподдерживаемом PHP — это 73,5%. Для такого сервера задача не сводится к установке свежего минорного релиза. Нужно перейти на поддерживаемую ветку, проверить фреймворк, расширения и собственный код, а иногда ещё дождаться решения от поставщика продукта.
Эксплуатация при этом ускоряется. Руководитель Cloudflare Мэттью Принс сообщил, что до публичного объявления сеть компании видела тысячи попыток использовать уязвимости; через 45 минут их были уже десятки тысяч, через два часа — сотни тысяч, а затем счёт пошёл на миллионы. Специалист по обнаружению и реагированию Perplexity AI Адель Карими также зафиксировал в своей honeypot-среде признаки удалённого выполнения кода против Apache mod_php с уязвимой версией PHP 8.4.26. Он отдельно оговорил, что такая среда намеренно удобна для атакующих, однако сам факт подтверждённой активности игнорировать трудно.
Некоторые операторы выбрали радикальную, но понятную меру: Wikimedia Foundation и Internet Archive временно отключали отдельные сервисы до установки обновлений. Американское агентство CISA внесло обе уязвимости в каталог Known Exploited Vulnerabilities и потребовало от федеральных гражданских ведомств устранить проблему до 29 октября 2026 года. Для российского бизнеса регуляторский дедлайн не действует, но логика та же: если обновление нельзя выполнить быстро и безопасно, публичный сервис стоит изолировать, ограничить доступ или временно вывести из эксплуатации, а не надеяться, что веб-фильтр заменит исправление рантайма.
Практический приоритет для команд сейчас — не искать обновление WordPress, Drupal или Joomla: проблема находится ниже уровня приложения, в PHP. Следует сопоставить все внешние точки входа с фактическим пакетом PHP и политикой бэкпортов у дистрибутива или хостера, применить подтверждённое исправление, перезапустить нужные процессы и проверить логи на признаки компрометации. Для систем на неподдерживаемых ветках нужен отдельный план миграции или поддерживаемый поставщиком патч. История PHP2Shell показывает неприятный тренд: находить сложные ошибки становится быстрее, а узким местом остаётся дисциплина обновлений и способность организаций точно знать, чем они владеют.
