Уязвимости PHP2Shell начали эксплуатировать практически сразу после раскрытия: Cloudflare зафиксировала тысячи попыток ещё до публичного объявления, десятки тысяч — в первые 45 минут после него, а затем счёт пошёл на миллионы. Для российских команд это не очередное напоминание «поставьте обновления», а проверка того, знают ли они вообще, где в их инфраструктуре работает PHP — от веб-приложений до камер и систем контроля доступа.
Речь идёт о критических CVE-2026-109618 и CVE-2026-109619. Как сообщает Dark Reading, 21 октября Check Point Research оценивала охват попыток эксплуатации уже в 10% организаций по всему миру. На другом конце этой гонки — патчинг: исследователи Ox Security спустя сутки после публикации исправленных версий видели обновление менее чем у 1% доступных для наблюдения инстансов. К утру 23 октября доля необновлённых экземпляров снизилась лишь до 97,5%.
Такие цифры не означают, что 97,5% компаний беззащитны: интернет-сканирование видит далеко не всё и часто ориентируется на наружу отданный номер версии. Но они хорошо показывают масштаб инерции. Flare обнаружила, что 73% публично видимых PHP-инстансов используют ветки, которые уже не поддерживаются PHP Foundation. Cisco Talos, опираясь на данные из открытых источников, предположила, что около половины PHP-систем вообще не получат патчи.
Сначала найти PHP, потом обновлять
Главная ловушка в истории с PHP2Shell — представление о PHP как о технологии исключительно для сайтов. В предупреждении CISA подчёркивается, что PHP часто встроен в другое ПО и может быть неочевиден для владельца инфраструктуры. Исследователь Flare Адриан Чик рассказывал, что PHP встречался не только на привычных веб-хостингах, но и в сетевых хранилищах, системах физического доступа, камерах и интерфейсах удалённого администрирования.
Если инвентаризация ограничена доменами компании и портами 80 и 443, часть поверхности атаки почти наверняка останется за кадром. Устройство может выглядеть как обычный NAS, камера или контроллер проходной, но внутри использовать уязвимый PHP-компонент. Самостоятельно обновить его, как правило, нельзя: нужен новый firmware от производителя. А для снятого с поддержки оборудования такого firmware может не существовать вовсе.
Поэтому первый практический шаг — не массово запускать обновления, а собрать полный список активов. В него должны попасть собственные приложения, контейнеры, виртуальные машины, панели администрирования, готовые продукты, устройства филиалов и облачные образы. Для каждого актива стоит установить, доступен ли он извне, какая версия и чей пакет PHP используется, есть ли патч от вендора, а также кто отвечает за сервис. Иначе аварийное обновление превратится в привычный корпоративный квест: уязвимость нашли, а владельца системы — нет.
Отдельная тонкость — старый номер версии не всегда равен отсутствию исправления. Dark Reading приводит характерный пример: PHP 7.4.3 поставлялся с Ubuntu 20.04, а Linux-дистрибутивы нередко переносят патчи безопасности в старую ветку, не меняя её публично видимый номер. Похожим образом могут поступать поставщики ПО, которые включают PHP в свой продукт. Командам безопасности полезно проверять бюллетени дистрибутива и производителя, состав пакета и фактически применённые исправления, а не делать вывод по одному баннеру сканера.
Что делать, если обновление сорвёт сервис
Там, где PHP действительно давно не поддерживается, простой апдейт может оказаться миграцией. Приложение на PHP 5 или PHP 7 способно зависеть от устаревших библиотек и поведения рантайма; переход на актуальный релиз потребует менять зависимости, перепроверять интеграции и тестировать бизнес-критичные сценарии. Это объясняет медленный темп реакции, но не отменяет риск: публичный сервис, который нельзя быстро исправить, становится удобной точкой входа.
Приоритет здесь должен определяться не возрастом стека, а экспозицией и ценностью системы. Узел без внешнего доступа и с жёстко ограниченной сетью — одна ситуация. Административная панель, публичный сайт, VPN-шлюз или устройство с доступом к корпоративной сети — совсем другая. Для неподдающихся немедленному патчингу систем разумны временные меры: ограничить доступ по сети, убрать интерфейс из интернета, разрешить подключение только через VPN или список адресов, усилить мониторинг и при необходимости отключить сервис до появления безопасного решения.
Чик также указал на точечное смягчение для CVE-2026-109619: если команда управляет конфигурацией PHP, можно отключить параметр session.upload_progress.enabled и перезапустить PHP-воркеры. Это перекрывает подтверждённые пути атаки через отслеживание загрузки в сессии. Но мера не закрывает CVE-2026-109618, поэтому воспринимать её как замену патчу было бы опасной экономией времени.
Параллельно стоит искать признаки уже состоявшегося компромисса: необычные процессы и дочерние веб-серверу процессы, новые файлы в каталогах приложений и временных директориях, подозрительные задания планировщика, исходящие соединения и аномалии в журналах HTTP/PHP. В этой истории скорость атакующих означает, что ответ «сначала обновимся, потом разберёмся» может опоздать.
PHP2Shell вновь показывает неприятную, но полезную закономерность: уязвимость в распространённом компоненте — это прежде всего тест качества учёта активов и отношений с вендорами. Пока компании не знают, какие встроенные компоненты живут в их устройствах и продуктах, даже своевременный патч остаётся лишь файлом, который некому и негде установить. Исходные цифры и комментарий главы Cloudflare можно сверить в материале .
