
В команде PHP Foundation представили технический отчёт о проблемах, возникших в процессе устранения исправленных ранее двух критических уязвимостей PHP2Shell в PHP (CVE-2026-109618 и CVE-2026-109619, которые потенциально могли привести к несанкционированному RCE. Но по факту оказалось, что в PHP нет простого способа эксплуатации этих уязвимостей.
По данным CERT-EU, исходя из оценки CVSS, обе уязвимости могут быть использованы без аутентификации. В PHP предупредили, что исправления критических проблем, обе с оценкой CVSS 9.2, запланированы на вечер среды 21 октября 2026 года. Проблема затрагивает все версии PHP, начиная с PHP 5. Уязвимы все PHP-установки, обслуживающие веб-запросы: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP и LiteSpeed. Команда PHP считает риск максимальным.
Уязвимости CVE-2026-109618 и CVE-2026-109619 связаны с разными проблемами при работе с памятью. Первая связана с нехваткой памяти: при очистке запроса программа может обратиться к некорректным данным, что способно привести к удалённому выполнению кода. При обработке последующих запросов программа может обратиться к устаревшим данным до полной инициализации состояния, что тоже грозит удалённым выполнением кода.
Команда безопасности PHP выпустила корректирующие выпуски PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35, а также патчи для уже не поддерживаемых веток PHP 7.4, PHP 8.0 и PHP 8.1, в которых исправлены критические уязвимости. В команде PHP призвали администраторов установить обновления. Заявлено, что полное блокирование уязвимостей возможно только через установку обновления.
По информации OpenNET, в PHP Foundation первая информация об уязвимости, возникающей при исчерпании доступной памяти, была получена в ходе внешнего аудита кода PHP в 2024 году. Тогда ошибку в коде восприняли лишь как теоретическую возможность совершения атаки. Исправление этой уязвимости затянулось из-за проблем с достижением консенсуса среди разработчиков PHP о способе устранения проблемы. В PHP Foundation рассматривали несколько способов решения проблемы, каждый из которых имел свои минусы. Разработчикам нужно было выбирать между нарушением обратной совместимости, появлением новых векторов для атак, вызывающих отказ в обслуживании, и необходимостью внесения изменений во множество сторонних дополнений.
В середине 2026 года ИБ-команды и Calif и Wiz независимо друг от друга и используя ИИ-системы GPT‑5.6 и Gemini 4 Argon выявили рабочие методы эксплуатации уязвимостей. В компаниях 11 августа и 24 августа 2026 года сообщили об этом разработчикам PHP. После этого разработке исправлений по устранению этих проблем был назначен наивысший приоритет. В PHP Foundation было начато реформирование процесса принятия решений для более оперативного реагирования в вопросах, связанных со сложными компромиссами. Например, подобные решения теперь могут приниматься разработчиками большинством голосов без строгого достижения консенсуса.
Изначально скоординированная с дистрибутивами дата публикации исправлений против уязвимостей PHP2Shell была назначена на 22 октября 2 026 года. Но затем этот срок был перенесён на 21 октября после утечки 20 октября в социальные сети сведений о CVE‑идентификаторах и некорректных данных о времени публикации предстоящих корректирующих выпусков.
Вскоре после анонса предстоящих исправлений против PHP2Shell в компания Calif, выявившая одну из уязвимостей, по ошибке опубликовала видеоролик с демонстрацией работы эксплоита, в котором были заметны некоторые детали, позволяющие сузить область поиска и воссоздания информации о проблеме. Видео удалили, но исследователи по всему миру начали работы по попыткам понять сути уязвимостей и даже начали выпускать альтернативные прототипы эксплоитов (не рабочие или с ограничениями, например, которые опираются на LFI (local file inclusion — включение локальных файлов).
За несколько часов до намеченной публикации исправлений против PHP2Shell в Chainguard нарушили эмбарго и опубликовали сборки своего дистрибутива, содержащие исправленную версию PHP. Подобное нарушение дало возможность злоумышленникам изучить исправление до официального релиза, а также перечеркнуло всю работу по скоординированному раскрытию информации и одновременной публикации исправлений в разных дистрибутивах.
Спустя 16 часов после раскрытия деталей об уязвимостях PHP2Shell универсального рабочего эксплоита в сети так и не появилось. Хотя, по данным Sansec, массовая эксплуатация, ожидалась в течение 15 минут после выхода патчей. В итоге не было массовых атак, что объясняется сложностью эксплуатации уязвимостей из‑за необходимости определения раскладки структур в памяти процесса, которая специфична в каждой сборке.
Оказалось, что опубликованные рабочие прототипы эксплойтов были завязаны на отдельные конфигурации и проведение атаки в лабораторных условиях. Также появилось много фиктивных эксплойтов, являющихся галлюцинациями ИИ, лишь создающих видимость атаки, завязанных на ошибки в конфигурации или работающих только при наличии других критических уязвимостей.
CVE-2026-109618 — удалённое выполнение кода, вызванное тем, что при исчерпании доступной процессу свободной памяти обработчик нехватки памяти через выполнение функции longjmp может прервать PHP-интерпретатор в состоянии, когда инициализирована лишь часть внутренних структур, связанных с обработкой запроса. В последующем функция завершения обработки запроса обращается к этим структурам как к уже инициализированным, хотя память для них не выделена.
Основным вектором атаки является манипуляция с multipart-запросами для создания условий для исчерпания доступной процессу памяти. Для обхода лимита post_max_size может не указываться заголовок Content-Length и передаваться огромное число HTTP-заголовков. Возможно проведение и точечных атак на конкретные операции в php-приложениях, чрезмерно расходующих память. Наличие эксплоита подтверждено для mod_php, так как он вызывает функцию shutdown() даже при сбое (PHP-FPM при сбое завершит дочерний процесс, что затрудняет проведение атаки, но теоретически её не исключает).
CVE-2026-109619 — удалённое выполнение кода, вызванное обращением к памяти после её освобождения из-за некорректной очистки глобального состояния, привязанного к конкретному запросу. В случае прерывания запроса из-за фатальной ошибки, таймаута или нехватки памяти глобальное состояние может оказаться не сброшено и указатели останутся активны, несмотря на освобождение памяти, на которую они ссылаются. При обработке следующего запроса в том же процессе может произойти обращение по оставшемуся указателю к старому глобальному состоянию.
Для эксплуатации этой уязвимости может использоваться создание условий исчерпания доступной памяти при обработке multipart-запроса в коде для индикации прогресса загрузки (session.upload_progress). При этом в качестве основного и подтверждённого вектора атаки упоминается обработчик fatal_error_backtraces в PHP 8.5, который не сбрасывает состояние трассировки при завершении. В первом случае атака возможна на mod_php и PHP-FPM, а во втором только на mod_php. Также упоминается неподтверждённая возможность проведения атаки в конфигурациях, в настройках которых имеются директивы, приводящие к выводу предупреждений на ранней стадии обработки запроса (например, предупреждения об использовании устаревших параметров).

1 час назад
3



English (US) ·
Russian (RU) ·