PHP2Shell вызвал миллионы атак: сайты срочно обновляют серверы

Две критические уязвимости в PHP перешли из стадии предупреждений в активную фазу: после публикации исправлений объём попыток эксплуатации вырос с тысяч до миллионов. По данным Cloudflare, которые приводит Reuters, сканирование и атаки резко ускорились после раскрытия деталей 21 октября. Организации и государственные ведомства в нескольких странах временно отключали сайты, пока администраторы устанавливали обновления.

Речь идёт о CVE-2026-109618 и CVE-2026-109619. Обе проблемы получили оценку 9,2 из 10 по шкале CVSS v4 и позволяют атакующему без предварительной авторизации добиться удалённого выполнения кода. PHP лежит в основе значительной части веб-сервисов, поэтому потенциальная зона риска включает корпоративные сайты, интернет-магазины, личные кабинеты, внутренние панели и приложения, которые прямо или косвенно используют уязвимые ветки языка.

Важно различать наблюдаемую активность и подтверждённые инциденты. Миллионы запросов — это попытки найти и атаковать уязвимые серверы, а не доказательство миллионов успешных взломов. Однако сочетание общедоступных технических деталей, высокой тяжести уязвимостей и большой установленной базы PHP делает окно между раскрытием и обновлением особенно опасным.

Что именно произошло

Разработчики PHP выпустили исправления 21 октября 2026 года для поддерживаемых веток. Исправленные версии — PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Qualys предупреждает, что уязвимости затрагивают механизм сериализации данных и могут привести не только к выполнению произвольного кода, но и к раскрытию содержимого памяти: паролей, токенов и API-ключей, если они присутствуют в процессе.

Palo Alto Networks Unit 42 оценила число доступных из интернета экземпляров PHP, которые потенциально могли требовать проверки и обновления, в 22,6 млн. Это не означает, что все они уязвимы: версия, конфигурация, способ использования и внешняя доступность отличаются. Но масштаб объясняет, почему автоматические сканеры начали работать почти сразу.

CERT-EU рекомендовала организациям срочно установить исправления и проверить журналы событий. Reuters сообщал, что часть правительственных и корпоративных ресурсов была временно выведена из сети как мера предосторожности. Само по себе отключение сайта не подтверждает компрометацию: в ряде случаев это контролируемая мера, позволяющая закрыть внешний доступ до завершения обновления и проверки.

Почему риск касается бизнеса, а не только ИТ-отдела

Успешная эксплуатация серверной уязвимости может затронуть сразу несколько контуров: работу сайта, данные клиентов, платёжные интеграции, корпоративные учётные записи и репутацию компании. Даже короткий простой интернет-магазина или сервиса поддержки превращается в прямые потери выручки. Если злоумышленник получил доступ к секретам приложения, одного обновления PHP уже недостаточно — потребуется расследование и замена скомпрометированных ключей.

Для банков, финтех-компаний и сервисов, работающих с персональными данными, важна не только техническая ликвидация риска, но и документирование действий: когда система была доступна извне, какая версия работала, были ли подозрительные запросы, менялись ли файлы, возникали ли неизвестные процессы. Эти сведения определяют, нужен ли полноценный разбор инцидента и уведомления по внутренним или регуляторным процедурам.

Облачная защита и веб-фильтры могут снизить число вредоносных запросов, но не заменяют обновление. Правила блокировки обычно реагируют на известные шаблоны, тогда как атакующие меняют формат запросов. Главная мера — перейти на исправленную версию и убедиться, что обновлён именно тот PHP, который обслуживает рабочее приложение, а не только пакет в неиспользуемом окружении.

Что делать владельцам сайтов прямо сейчас

Сначала нужно провести инвентаризацию: определить версии PHP на внешних и внутренних серверах, в контейнерах, образах, панелях хостинга и средах резервного запуска. Затем обновить поддерживаемую ветку как минимум до исправленного релиза и перезапустить зависимые процессы. После обновления следует проверить, что сервис действительно использует новый бинарный файл и что автоматическое развёртывание не вернёт старый образ.

Параллельно администратору стоит сохранить и проанализировать журналы веб-сервера, PHP, системы и средств защиты за период до и после раскрытия. Необычные запросы, новые файлы, задания планировщика, неизвестные процессы или исходящие соединения требуют эскалации в команду реагирования. При наличии признаков компрометации необходимо изолировать узел, восстановить его из доверенного образа и заменить секреты — пароли, токены, ключи API и сертификаты — в соответствии с планом реагирования.

Если быстро обновить систему невозможно, безопаснее временно ограничить внешний доступ к уязвимому приложению, чем полагаться только на фильтры. Это решение должно учитывать критичность сервиса и бизнес-процессы, но откладывать исправление до планового окна в данной ситуации рискованно.

Что это значит

Для владельцев сайтов это не обычное обновление «на потом»: нужно сегодня подтвердить рабочую версию PHP, установить патч и проверить журналы. Для руководителей задача — обеспечить окно на обновление и расследование, даже если потребуется кратковременный контролируемый простой. Обычным пользователям не нужно самостоятельно обновлять PHP: при недоступности сервиса следует пользоваться только его официальными каналами и не вводить данные на похожих доменах, которые предлагают «запасной вход».