Критические уязвимости в PHP (CVE-2026-109618, CVE-2026-109619): разбор и план действий

20 октября 2026 года PHP Foundation анонсировал внеплановый security-релиз, устраняющий две критические уязвимости, которые могут привести к удаленному выполнению кода (RCE). Сегодня, 21 октября, CERT-EU опубликовал бюллетень Security Advisory 2026-018, в котором присвоил уязвимостям идентификаторы CVE-2026-109618 и CVE-2026-109619 и настоятельно рекомендовал организациям подготовиться к немедленному патчингу.

На момент публикации бюллетеня технические детали уязвимостей не раскрыты, однако известна их оценка по шкале CVSS — 9.2 (Critical), что указывает на потенциальную возможность неаутентифицированного удаленного выполнения кода. Публичные источники сообщают о воспроизведении эксплойта (получившего название php2shell) и о первых попытках эксплуатации в реальных атаках, что переводит ситуацию в категорию высокого операционного риска.

 

Что известно на текущий момент

• Уязвимости: CVE-2026-109618 и CVE-2026-109619, обе — RCE, CVSS 9.2 (по версии PHP Security Team); некоторые источники указывают на CVSS 10.0, однако официальная оценка — 9.2.
• Затронутые версии: по данным CERT-EU, потенциально все версии PHP, начиная с PHP 5. Официальный список затронутых и исправленных версий будет опубликован вместе с релизом; ожидается, что патчи получат только поддерживаемые ветки — PHP 8.2–8.5. Ветки PHP 8.1, 8.0, 7.x и 5.x являются end-of-life и, вероятно, не получат исправлений.
• Плановый релиз: 21 октября 2026 года в 14:00 UTC (17:00 МСК).
• Статус эксплуатации: Cloudflare и Patchstack сообщают о ранних попытках эксплуатации; CERT-EU и ACSC (Австралия) на момент выпуска бюллетеня не подтверждали наличие публичного эксплойта в открытом доступе, однако призывали не дожидаться патча.

 

Почему это важно для вашей инфраструктуры

PHP остается одной из самых распространенных серверных технологий: на нем работают WordPress, Drupal, Joomla, Magento, панели управления (cPanel, Plesk), shared-хостинг и множество кастомных веб-приложений. Уязвимость в самом интерпретаторе означает, что вопрос не в том, «какое из ваших приложений затронуто», а в том, где в вашей инфраструктуре вообще используется PHP, включая скрытые зависимости, вендорные appliances и унаследованные системы.

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

 

План действий: что необходимо сделать

Шаг 1. Инвентаризация PHP-активов (немедленно, до выхода патча)

Составьте перечень всех систем, где используется PHP: веб-серверы, приложения, вендорные appliances, панели управления, Windows-ПО со встроенным PHP, контейнеры и shared-хостинг. Зафиксируйте версию PHP для каждого актива. Приоритет — интернет-доступные сервисы.

Шаг 2. Подготовка к патчингу

Определите окно обслуживания с учетом планового релиза (21 октября, 14:00 UTC). В первую очередь патчите интернет-доступные системы. Используйте официальные номера версий из анонса PHP и проверяйте backported-пакеты у дистрибутивов Linux и хостинг-провайдеров. Для контейнеризированных сред заранее подготовьте обновление базовых образов.

Шаг 3. Если немедленный патчинг невозможен — изоляция

CERT-EU прямо рекомендует: если немедленное исправление невыполнимо, рассмотрите изоляцию интернет-доступных приложений от публичных сетей до появления исправления. Практические меры:

• вывести сервис из публичного периметра (VPN, reverse-proxy с аутентификацией);
• ограничить доступ по IP-адресам (allow-list);
• активировать режим «maintenance» для критичных, но не готовых к патчу систем;
• при наличии WAF оперативно развернуть виртуальные патчи (Cloudflare и другие вендоры уже добавляют правила).

Шаг 4. Работа с end-of-life версиями PHP

Для систем на PHP 8.1 и старше вендорского патча не будет. Планируйте миграцию на поддерживаемую ветку, а до завершения миграции размещайте такие системы за VPN или WAF, либо изолируйте от интернета.

Шаг 5. Пост-патч: проверка компрометации

После установки исправлений проведите анализ журналов веб-сервера, PHP и системы на предмет подозрительной активности (аномальные POST-запросы, загрузка файлов, изменения в файловой системе, новые процессы). Обновите правила мониторинга и убедитесь, что вторичные компоненты не вернули уязвимость.

Шаг 6. Не полагайтесь на неподтвержденные источники

Публичные обсуждения уязвимости сопровождаются утечками и спекуляциями. Для принятия решений используйте официальные бюллетени CERT-EU, PHP Security Team и национальных CERT. Не применяйте непроверенные эксплойты и «временные патчи» из неофициальных источников — это создает дополнительный риск компрометации.

 

Вывод

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

Мы будем отслеживать обновления бюллетеня CERT-EU 2026-018 и оперативно информировать о выходе официальных патчей и дополнительных рекомендациях.

 

Источник

CERT-EU Security Advisory 2026-018

 

Протестируйте бесплатно