Разработчики PHP выпустили экстренные обновления для двух уязвимостей с оценкой CVSS 9,2, способных привести к удалённому выполнению кода без авторизации. Критические уязвимости PHP затрагивают веб-серверы с PHP-FPM, mod_php, php-cgi, FrankenPHP и LiteSpeed — то есть проблему стоит искать не только в исходниках приложения, но и в инфраструктуре, которую обычно называют «настроенной и забытой».
Исправления вошли в PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Они закрывают CVE-2026-109618 и CVE-2026-109619. Проект PHP призвал администраторов обновиться немедленно, сообщает The Register. Если быстрый патч невозможен, европейская команда реагирования на инциденты CERT-EU рекомендует изолировать публичные приложения от интернета до установки исправлений.
Обе ошибки опасны тем, что атака не требует учётной записи. Разработчики отдельно выделили конфигурации с Apache mod_php: для них уже показан сценарий, при котором вредоносный запрос срабатывает ещё до выполнения кода самого сайта. Практически это означает, что привычные меры на уровне CMS — авторизация в админке, плагины защиты или аккуратная валидация форм — могут не успеть включиться.
Первые признаки эксплуатации уже появились. Джейк Нотт, руководитель threat intelligence в watchTowr, сообщил, что датчики компании фиксируют попытки атак и несколько вариантов proof-of-concept с User-Agent, содержащим строку «php2shell». На момент его комментария успешного взлома через эти попытки не наблюдали, но рассчитывать на долгое окно безопасности было бы излишним оптимизмом: после публичных PoC эксплуатация таких ошибок обычно быстро автоматизируется.
Реакция организаций показывает, насколько серьёзно оценили риск. В качестве меры предосторожности в Финляндии временно отключали государственные сервисы, а в Нидерландах — сайты парламента, органов кибербезопасности и регулятора по защите данных. Сайт правозащитной организации noyb также на время убрали из публичного доступа. Выключить сервис неприятно, но при неаутентифицированном RCE это часто менее болезненный сценарий, чем разбираться с последствиями компрометации.
Для российского рынка масштаб задачи определяется не только числом собственных PHP-проектов. PHP остаётся основой WordPress, Drupal, Joomla, Magento, панелей управления хостингом и множества внутренних систем, где технологический стек не всегда очевиден владельцу продукта. В компании может не быть ни одного репозитория с расширением .php в активной разработке, но веб-сайт, личный кабинет, витрина магазина или серверная панель всё равно могут зависеть от уязвимого интерпретатора.
Проверку разумно начинать с инвентаризации внешних точек входа: виртуальных машин, контейнеров, shared hosting, managed-платформ и серверов с нестандартными образами. Затем нужно сопоставить фактические версии PHP с исправленными релизами и убедиться, что обновлён именно runtime, обслуживающий веб-запросы, а не только CLI-интерпретатор. Отдельного внимания требуют Apache с mod_php, старые образы в CI/CD и резервные площадки: во время инцидента именно они любят внезапно становиться основным продакшеном.
До патча стоит ограничить публичный доступ к затронутым приложениям, где это допустимо для бизнеса, и усилить наблюдение за веб-логами, особенно за необычными запросами и User-Agent. После обновления полезно проверить, не появились ли на сервере незнакомые процессы, задания планировщика, файлы в каталогах загрузок и изменения конфигурации. Патч закрывает вход, но не отменяет расследование, если попытки эксплуатации уже были.
Критические уязвимости PHP вновь напоминают, что поддержка веб-стека — это не только обновление зависимостей приложения. Для команд разработки и эксплуатации ближайшая проверка проста по формулировке, но может оказаться длинной по исполнению: нужно понять, где именно PHP принимает внешние запросы, и убедиться, что ни один такой экземпляр не остался на старой версии.
