Критические RCE в PHP: патчи CVE-2026-109618 и 109619

21 октября 2026 года команда разработчиков PHP выпустила обновления безопасности 8.5.12, 8.4.27, 8.3.36 и 8.2.35, закрывающие две критические уязвимости, получившие в профессиональном сообществе название «php2shell»: CVE-2026-109618 и CVE-2026-109619. Обе ошибки позволяют выполнить произвольный код удаленно (RCE) без аутентификации на уязвимых веб-серверах. Главный вывод разработчиков PHP однозначен: обновление среды выполнения PHP — единственный полный способ защиты.

Поскольку PHP используется примерно на 70 % сайтов с известным серверным языком, выпуск обновлений сопровождался экстренными бюллетенями национальных и европейских центров реагирования на компьютерные инциденты, включая CERT-EU (бюллетень 2026-018) и Национальный центр кибербезопасности Нидерландов (NCSC-NL). В Европе и других регионах ряд государственных порталов и корпоративных веб-сервисов временно переводили сайты в режим обслуживания на время установки патчей.

Преждевременная утечка CVE, хронология открытия и техническая суть

Согласно техническому разбору The PHP Foundation, особенности обработки нехватки памяти (OOM), лежащие в основе CVE-2026-109618, впервые были замечены еще в 2024 году в ходе внешнего аудита OSTIF и Quarkslab при поддержке Sovereign Tech Agency. Тогда сценарий эксплуатации считался теоретическим, а предложенные правки несли риск нарушения обратной совместимости с расширениями. Ситуация изменилась после включения PHP в программу Patch the Planet в конце июля 2026 года: 11 августа 2026 года исследователь Райан Остин из компании Calif (под руководством Тхая Зыонга) доказал возможность безусловного удаленного выполнения кода и передал отчет Фолькеру Душу в The PHP Foundation. В тот же день OpenAI независимо сообщила о той же первопричине, а 24 августа Wiz и 18 сентября OpenAI представили дополнительные векторы атаки.

Процесс координированного раскрытия был нарушен примерно за сутки до релиза. Около 15:00 UTC 20 октября оба идентификатора CVE и их заголовки попали в публичные ленты уязвимостей до выхода исправленных пакетов, что вынудило CERT-EU и NCSC-NL выпустить срочные предупреждения. При этом важно отметить: временная недоступность ряда сайтов 20 и 21 октября была вызвана превентивным отключением ресурсов самими администраторами до выхода патча, а не подтвержденными разрушительными атаками.

С технической точки зрения CVE-2026-109618 (GHSA-w8hw-w9fx-j79w, NVD) возникает из-за некорректной очистки структур данных при нехватке памяти (OOM) во время разбора входящего запроса, что ведет к повреждению памяти и RCE (CWE-119, CWE-787). CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp, NVD) представляет собой уязвимость обращения к освобожденной памяти (use-after-free, CWE-416), при которой внутреннее состояние отслеживания загрузки сессии или трассировки фатальных ошибок сохраняется после освобождения памяти запроса. PHP оценивает обе уязвимости в 9,2 балла (критический уровень) по CVSS v4.0, а NVD — в 9,8 балла по CVSS v3.1.

Уязвимые конфигурации и исправленные версии

В официальном уведомлении PHP подчеркивается, что риску подвержены все установки PHP, обрабатывающие веб-запросы, включая PHP-FPM, Apache mod_php, php.exe, CGI/FastCGI, а также среды с долгоживущими рабочими процессами, такие как FrankenPHP, RoadRunner и Swoole. Наибольшему риску подвержены конфигурации Apache mod_php, где все потоки разделяют общее адресное пространство процесса.

Администраторам, использующим PHP-FPM, также не следует терять бдительность. Хотя изоляция процессов в FPM снижает риск по линии CVE-2026-109618, механизм отслеживания прогресса загрузки сессий в CVE-2026-109619 включен по умолчанию и может эксплуатироваться на стандартных установках FPM без какого-либо специального PHP-скрипта. Исследователи подтвердили полное удаленное выполнение кода как для mod_php, так и для FPM. Кроме того, в аналитическом разборе Tenable отмечается, что главный процесс FPM автоматически перезапускает упавшие воркеры, поэтому внешне стабильная работа сервиса не гарантирует отсутствие попыток взлома; Tenable также предупреждает о поддельных репозиториях «php2shell PoC» на GitHub, распространяющих вредоносное ПО класса infostealer.

Официальные исправленные выпуски для поддерживаемых веток — PHP 8.5.12, PHP 8.4.27, PHP 8.3.36 и PHP 8.2.35. Учитывая критичность проблемы, команда PHP также опубликовала ветки с минимальными патчами исходного кода для снятых с поддержки версий PHP 7.4, 8.0 и 8.1. В дистрибутивах Linux, таких как Debian и Ubuntu, исправления переносятся (backport) в существующие версии пакетов дистрибутива, поэтому необходимо сверять точную версию установленного пакета с бюллетенями безопасности дистрибутива, а не ориентироваться только на вывод команды php -v (Debian Security Tracker, Ubuntu Security).

Порядок действий и временные меры защиты

1. Инвентаризация сред PHP: Выявите все экземпляры PHP, принимающие внешние или внутренние HTTP-запросы — пулы FPM, Apache mod_php, контейнерные образы и воркеры FrankenPHP, RoadRunner или Swoole — и закройте публичный доступ к страницам диагностики с phpinfo().

2. Обновление и перезапуск рабочих процессов: Обновите PHP до версий 8.5.12, 8.4.27, 8.3.36 или 8.2.35 (либо до пропатченного пакета вашего дистрибутива Linux) и обязательно перезапустите как веб-сервер, так и все рабочие процессы PHP-FPM, чтобы в оперативной памяти не осталось старых бинарных файлов.

3. Временные ограничения конфигурации (только до установки патча): Разработчики PHP подчеркивают, что настройки конфигурации лишь сужают отдельные векторы атаки и не делают систему безопасной без обновления. До установки патча поверхность атаки CVE-2026-109618 можно сократить, задав memory_limit=-1 через php_admin_value (чтобы приложение не могло изменить его через ini_set() или .user.ini) и уменьшив post_max_size и upload_max_filesize; при этом нельзя задавать системные лимиты RLIMIT_AS или RLIMIT_DATA, иначе ошибка нехватки памяти возникнет еще раньше. Для CVE-2026-109619 следует установить session.upload_progress.enabled=0 и (в PHP 8.5) fatal_error_backtraces=0, учитывая, что оператор подавления ошибок @ все равно создает внутренние структуры ошибок даже при отключенных error_reporting и display_errors.

4. Проверка журналов сбоев: Изучите журналы FPM и веб-сервера на предмет повторяющихся падений воркеров (SIGSEGV или OOM), аномально крупных multipart-запросов и подозрительных обращений к механизму загрузки сессий. Отсутствие подозрительных записей в обычных HTTP-логах доступа само по себе не доказывает отсутствие атак, поскольку запросы, вызывающие аварийное завершение воркера, часто не фиксируются в стандартном access-логе.

Взгляд LeakData: Как защитить учетные данные и данные пользователей после серверных уязвимостей

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

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

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