PHP закрыл две критические RCE-уязвимости PHP2Shell

Подробно

Что за уязвимости PHP2Shell и как они устроены?

Проект PHP описывает две ошибки безопасности памяти в ядре языка. Обе допускают выполнение кода без аутентификации при подходящих условиях, оценка по CVSS v4.0 - 9,2 балла.

• CVE-2026-109618 - повреждение памяти при обработке нехватки памяти (out-of-memory). Аварийный выход может оставить внутренние структуры запроса частично инициализированными, после чего очистка использует их как корректные.
• CVE-2026-109619 - use-after-free из-за устаревшего глобального состояния. Данные одного запроса продолжают указывать на уже освобождённую память, а следующий запрос к тому же worker-процессу может их использовать.

Исследователи объединили найденные примитивы в эксплойт php2shell. Wiz показала выполнение кода без аутентификации на актуальных на момент теста контейнерных образах WordPress, Drupal и Joomla. Calif сообщает о подтверждённой RCE без аутентификации на WordPress 7.1.2, Drupal 11.4.3, Joomla 6.1.4, MediaWiki 1.46.2, Roundcube 1.7.4, Magento 2.4.9, phpMyAdmin 5.2.3, Nextcloud 35.0.1, Laravel 13.11, Symfony 8.1 и WHMCS, а в некоторых конфигурациях - и на произвольных PHP-скриптах. Уязвимость находится в самом PHP, поэтому наличие именно этих CMS не обязательно.

Кого затрагивают уязвимости и как защититься?

В зоне потенциального риска находятся PHP-установки, обслуживающие веб-запросы: PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Наивысший подтверждённый риск у mod_php: эксплуатация может начаться до выполнения прикладного PHP-кода.

Исправленные версии - PHP 8.2.35, 8.3.36, 8.4.27 и 8.5.12. Ветки PHP 8.1 и старше не получают обычных обновлений, но команда опубликовала минимальные исходные backport-патчи для PHP 7.4, 8.0 и 8.1.

Обновление остаётся единственным полным исправлением. Настройки memory_limit и post_max_size, отключение session.upload_progress и ограничения загрузок могут уменьшить поверхность атаки, но PHP прямо предупреждает, что они не делают систему безопасной. Cloudflare включила правила WAF для бесплатных и платных клиентов 21 октября в 03:02 UTC, примерно за девять часов до раскрытия. Компания отмечает, что WAF - дополнительный слой, а не замена обновлению, и что атакующие меняют payload, пытаясь обойти правила.

«Если вы используете PHP, крайне важно обновиться сейчас», - заявила PHP Foundation, сопровождающая релиз.

Началась ли эксплуатация за четыре дня до патча?

Частично. Amazon Threat Intelligence обнаружила в телеметрии MadPot одну попытку эксплуатации от 17 октября с IP-адреса коммерческой сети анонимизации. AWS не знает, как отправитель получил сведения об эксплойте, не установила, была ли попытка успешной, и продолжает технический анализ.

21 октября около 02:00 UTC AWS увидела публичные proof-of-concept, а с 02:00 до 08:00 UTC - дополнительные попытки с другой анонимизирующей инфраструктуры, что указывает на нескольких участников. После снятия эмбарго и выхода патча в 14:00 UTC новые PoC появились в течение нескольких часов и почти сразу применялись против сенсоров AWS. Именно на этом этапе AWS называет PHP2Shell широко эксплуатируемой в интернете.

«С PHP2Shell компрометация могла предшествовать бюллетеню», - заявил CJ Moses, CISO Amazon Integrated Security. AWS рекомендует начинать ретроспективное расследование как минимум с 17 октября и патчить критические интернет-доступные системы в течение часов, а не по SLA в 7 или 30 дней.

Публичных данных о числе скомпрометированных сайтов, похищенных данных, ущербе и атрибуции атакующих на 22 октября нет.

Кто и как нашёл уязвимости PHP2Shell?

Проект Patch the Planet запустили OpenAI и Trail of Bits для аудита и исправления открытого ПО. Calif начала аудит PHP 30 июля 2026 года в рамках программы. Исследователь Ryan A сообщил PHP Foundation о безусловной RCE с корнем в OOM-проблеме 11 августа, OpenAI независимо сообщила о том же корне в тот же день и передала дополнительные векторы 18 сентября.

По хронологии Wiz, её исследователи нашли первую уязвимость 19 августа, подтвердили RCE без аутентификации на Drupal 20 августа и на WordPress 21 августа, а 24 августа сообщили об уязвимостях команде PHP. Wiz использовала Wiz Atlas, GPT-5.6 Sol и Gemini 4 Argon и особо выделяет вклад Gemini 4 Argon. Раллука Ада Попа (Raluca Ada Popa), руководитель направления Gemini Security в Google DeepMind, заявила, что модель помогла защитникам найти уязвимости и подготовить исправление.

OpenAI формулирует вклад иначе: Calif нашла критическую уязвимость с GPT-5.6 Sol, а Wiz независимо нашла и сообщила обе. Поэтому утверждение «модели OpenAI нашли обе уязвимости» упрощает картину. OpenAI заявляет: «Насколько нам известно, передовой ИИ нашёл эти уязвимости раньше атакующих». Однако попытка 17 октября не доказывает, что атакующие обнаружили ошибку раньше исследователей, и не опровергает этого.

Формального сравнительного бенчмарка моделей не публиковали. Источники - технические отчёты компаний и GitHub-бюллетени, а не рецензируемые работы.

Правда ли, что уязвимостям 22 года и затронуты все версии PHP?

Первоисточники этого не подтверждают. Calif датирует самый ранний найденный уязвимый путь версией PHP 5.4.0. Дата 2004 года относится к другой, более ранней уязвимости, связанной с memory_limit и исследованной Стефаном Эссером. Она стала отправной точкой поиска, но не доказывает возраст CVE-2026-109618 и CVE-2026-109619. Набор доступных цепочек зависит от версии PHP, SAPI, конфигурации, расширений, приложения, раскладки памяти и распределения запросов между worker-процессами.

Оценки тоже различаются. Red Hat оценивает CVE-2026-109618 в 8,1 балла по CVSS v3 и как Important, а не Critical: типовые развёртывания RHEL используют PHP-FPM, где эксплуатация сложнее и обычно требует прикладного пути после запуска запроса. Это оценка конкретных конфигураций, а не опровержение 9,2 балла от PHP. Для CVE-2026-109618 бюллетень PHP подтверждает полный RCE на mod_php. Для PHP-FPM он признаёт восприимчивость, но не универсальный эксплойт, хотя Calif отдельно показывает прикладные цепочки для FPM. Цифру «около 70% сайтов» Wiz и Cloudflare приводят как оценку распространённости PHP, а не число сайтов, уязвимых к одной цепочке.

Почему проблема не была исправлена раньше?

OOM-проблему замечали и прежде. В 2020 году в PHP bug #78876 сообщили, что длинные переменные способны вызвать нехватку памяти и нарушить очистку временных файлов, но практическая RCE показана не была. В 2024 году внешний аудит PHP от OSTIF и Quarkslab вновь выявил связанную проблему. Эксплуатируемость предполагали, но вектор не доказали, и исправление застопорилось.

PHP Foundation назвала это «структурным провалом, вызванным и процессом принятия решений security-команды, и нехваткой ресурсов».

Перед релизом произошла утечка номеров: 20 октября около 15:00 UTC в форумах и соцсетях начали распространяться CVE-номера с ошибочной оценкой CVSS 10,0 и неверным временем релиза. По данным PHP Foundation, технические подробности тогда не утекли. В 19:30 UTC PHP опубликовал предупреждение и перенёс релиз с 22 октября на 21 октября, 14:00 UTC.

По публичному счётчику Patch the Planet, в программе 68 исследуемых кодовых баз, найдено 1995 проблем, написано 679 патчей, из них 466 приняты разработчиками.