CVE-2026-109618 и CVE-2026-109619 — потенциально удалённое выполнение кода на любом сервере, выполняющем PHP-скрипты. Затронуты все версии, обслуживаемые проектом PHP. Экстренные выпуски — 8.5.12, 8.4.27, 8.3.36, 8.2.35 — вышли 21.10 в 17:00 МСК.
Собрано по официальным источникам: бюллетень PHP Security Team, сообщение «1С-Битрикс», opennet.ru · 21.10.2026
Про эту дыру сейчас пишут все, в обсуждениях её называют PHP2Shell. Пересказывать шум незачем — важнее масштаб, который в этом шуме теряется.
В самом языке PHP, а не в CMS или фреймворках. Детали официально раскрывают только вместе с исправлениями.
PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35 закрыли обе уязвимости. Опубликован security advisory: ставить незамедлительно.
Патчи доступны, но детали уже обсуждаются открыто: CERT-EU сообщает, что начали распространяться первые proof-of-concept, и это повышает вероятность уже идущей эксплуатации. Пока не обновились — сервер остаётся уязвимым. Облачный Битрикс24 держит временные ограничения до завершения проверок.
В обсуждениях уровень называют «князь тьмы». Формально — критический RCE без авторизации, и вот почему это касается всех.
Потенциально удалённое выполнение кода на сервере — высшая категория угрозы
По открытой информации проблема проявляется во всех версиях с PHP 5.4; полные патчи — для 8.2–8.5, для 7.4–8.1 только минимальные бэкпорты исходников
CVE-2026-109618 и CVE-2026-109619 закрываются одним экстренным выпуском
Оценка обеих уязвимостей по CVSS v4.0 (указана в анонсе PHP Security Team). В списке CISA KEV записей по этим CVE на момент обновления нет
CVE-2026-109618 — RCE через повреждение при нехватке памяти. Ошибка выделения памяти прерывает PHP на полпути инициализации данных запроса; при очистке некорректные данные трактуются как валидные.
CVE-2026-109619 — RCE через «протухшее» глобальное состояние. Внутреннее состояние запроса переживает освобождение памяти; следующий запрос в том же воркере использует его до сброса.
Как именно подводят запросы (по подробному разбору opennet.ru от 17:45 МСК): основной вектор — multipart-запросы, которыми атакующий доводит процесс до исчерпания памяти. Чтобы обойти post_max_size, запрос можно слать без заголовка Content-Length и с огромным числом HTTP-заголовков. Для 109619 подтверждённый вектор — обработчик fatal_error_backtraces в PHP 8.5, который не сбрасывает трассировку при завершении; плюс неподтверждённая возможность через директивы, дающие предупреждения на ранней стадии разбора запроса.
Под ударом любая схема, отдающая веб: PHP-FPM, Apache + mod_php, php-cgi, FrankenPHP, LiteSpeed — а значит WordPress, Bitrix, Laravel и любой сайт на PHP. Хуже всего mod_php: там показали эксплойт, срабатывающий раньше, чем запустится хоть строчка кода сайта (mod_php вызывает shutdown() даже при сбое). PHP-FPM при падении убивает дочерний процесс — это мешает атаке, но теоретически её не исключает. Идеально написанный код приложения не спасает.
Общий корень обеих дыр (по разбору Unit 42 и CERT-EU): longjmp(), которым PHP прерывает запрос при превышении memory_limit или при fatal error. После такого прыжка память запроса остаётся неинициализированной (109618) либо указывает на уже освобождённые области (109619) — следующие запросы того же воркера читают по ним и выполняют код.
PoC уже гуляют публично. Unit 42 (Palo Alto Networks) пишет, что видела proof of concept обеих уязвимостей. CERT-EU в advisory 2026-018 (21.10, v1.1): детали открыто обсуждаются, распространение первых PoC началось, а значит вероятность реальной эксплуатации резко растёт. При этом в списке CISA KEV записей по этим CVE нет (проверено по каталогу от 21.10.2026) — официального подтверждения атак в дикой природе на данный момент нет.
Оценки масштаба. По телеметрии Palo Alto Networks Cortex Xpanse в интернете обнаружено более 22,6 млн выставленных экземпляров, потенциально уязвимых к этим CVE. Что именно входит в эту выборку и какова доля реальных серверов PHP — источник не уточняет, цифра отражает поверхность exposure, а не число взломов.
Первая превентивная жертва — не взлом, а отключение. По данным Unit 42, как минимум одно европейское государственное ведомство временно убрало свой сайт из сети в качестве меры предосторожности.
Под ударом не только сайты. CERT-EU и NCSC-NL (репозиторий php2shell) предупреждают: PHP вшит в устройства, сетевые appliance, панели управления и сторонние продукты, где администратор не может обновить интерпретатор напрямую. Образы, прошивки и вендорские пакеты проверять отдельно — в репозитории NCSC-NL есть список зависимого ПО.
Позиция Битрикс24 и общий случай — три сценария.
Обновлять PHP самому не нужно — серверы обслуживает вендор. Он уже принял меры и временно ограничил часть возможностей (например, работу с формами и файлами) до установки исправлений и проверок.
Это не авария, а осознанная крайняя мера. О восстановлении функций сообщат отдельно.
PHP обновляет специалист, обслуживающий сервер: системный администратор, интегратор или хостинг. Самому разбираться в технических настройках не нужно — передайте задачу.
Перешлите эту страницу админу прямо сейчас: выпуски уже вышли — пусть ставит, а до обновления ставит ограничители из раздела ниже.
WordPress, Bitrix, Laravel, 1С-Битрикс, самописные CMS, панель хостинга — всё крутится на одном интерпретаторе. Значит под ударом любой сайт на PHP. Рекомендация одна: немедленно установить 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 — они уже опубликованы.
Нет доступа к серверу прямо сейчас — сначала ограничители из раздела ниже, потом обновление.
Патчи уже опубликованы — вопрос не «когда», а каким путём обновляться именно вам. Четыре типичных сценария.
Официальные выпуски 8.5.12, 8.4.27, 8.3.36, 8.2.35. Исходники и бинарники для Windows — на странице загрузок php.net. PHP 8.2 уходит в end-of-life 31 декабря 2026 — после этой даты security-фиксов для 8.2 не будет вовсе, планируйте переезд на 8.3+.
Вендоры дистрибутивов получили патчи заранее — пакеты уже выходят. Пример Debian: 8.4.27-1~deb13u1 для trixie (DSA-6574-1) и 8.2.35-1~deb12u1 для bookworm (DLA-4848-1). Проверяйте свой репозиторий или трекер безопасности.
Волонтёрский rpms.remirepo.net обновлений в день релиза не дал. Берите пакеты дистрибутива или собирайте из исходников — сам репозиторий сейчас не вариант.
Штатных обновлений нет — версии давно без поддержки. Но security team выложила минимальные бэкпорты в исходниках: собрать PHP самому, дождаться бэкпорта дистрибутива — или переехать на 8.2+.
Формулировка самих разработчиков PHP: эти меры снижают риск по конкретным путям атаки, но не делают установку безопасной. Нормальной замены обновлению не существует.
Перекрыть подтверждённые сессионные пути:
session.upload_progress.enabled = 0Только в php.ini, пуле FPM или конфиге сервера — там, где настройка применяется до разбора запроса. ini_set() и .user.ini не работают. После смены — перезапустить всех воркеров.
fatal_error_backtraces = 0 // только на PHP 8.5Убрать по-запросные настройки, которые выдают диагностику до инициализации. Прятать ошибки через error_reporting, display_errors или @ — бесполезно.
Убрать управляемый отказ лимита памяти — так, чтобы приложение не могло вернуть его обратно:
php_admin_value[memory_limit] = -1 // пул FPM / ApacheПлюс низкий post_max_size: 8M без загрузок файлов, 32M если загрузки нужны; upload_max_filesize — ниже post_max_size.
Лимиты на веб-сервере/прокси: размер декодированного запроса, число полей, частей multipart, заголовков, глубина вложенности — в том числе для запросов без валидного Content-Length.
Контейнер/cgroup — как граница доступности, убивающая только воркер. RLIMIT_AS/RLIMIT_DATA не использовать: они могут сами вызвать уязвимый отказ выделения.
В разборе opennet.ru отмечается более жёсткая мера — полная блокировка запросов с типом контента multipart/form-data. Она перекрывает основной вектор, но ломает загрузку файлов через веб-формы — применима только там, где загрузок нет (например, чисто API- или корпоративный сайт без файловых форм). Правила со страницы opennet.ru:
# Apache (mod_rewrite)
RewriteCond %{HTTP:Content-Type} multipart [NC]
RewriteRule ^ - [F,L]# nginx
if ($http_content_type ~* "multipart") { return 403; }# Caddy
@multipart header_regexp Content-Type (?i)multipart
respond @multipart 403Это не официальная рекомендация PHP Security Team, а обсуждаемая мера. И она не защищает от вариантов атаки, не связанных с multipart: единственный полный фикс — обновление.
Это бинты, а не лечение — так сказано в официальном advisory. Как только появится доступ к серверу: ставить 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 и проверять формы, загрузки и авторизацию после обновления.
Отдельно проверьте вендорские образы, appliance и панели, куда PHP вшит (NCSC-NL ведёт список зависимого ПО) — там обновление возможно только через прошивку/пакет вендора. Если патч совсем недоступен, CERT-EU советует на время убрать публичный сервис из интернета — именно так поступило как минимум одно европейское госведомство.
Пройдите по пунктам — каждый занимает минуты.
php -v в консоли, а ту, что работает в FPM/Apache. Панель хостинга или phpinfo() через браузер.На всех наших системах фикс уже катится. Экстренное обновление PHP на вашем VPS или выделенном сервере, настройка пулов FPM, проверка форм, загрузок и авторизации после патча — берём на себя. Если серверы — ваша зона ответственности, но разбираться в 17:00 пятницы нет ни сил, ни времени, напишите нам.
Пишите в Telegram @andrew_zahalski — ответим и начнём в день обращения