PHP2Shell (CVE-2026-109618 и CVE-2026-109619): Обнаружение неаутентифицированного удаленного выполнения кода в ядре PHP

21 октября 2026 года CVE-2026-109618 и CVE-2026-109619, получившие название PHP2Shell, были исправлены в двух экстренных релизах от проекта PHP. Эти два CVE объединяют четыре связанных бага безопасности памяти, и обе уязвимости имеют оценку CVSS v4.0 9.2. Неаутентифицированный злоумышленник может использовать их для запуска кода на PHP-сервере с помощью одних лишь HTTP-запросов. В обращении находится несколько работающих концепт-прототипов (PoC) эксплойтов, а исследователи, сообщившие об уязвимостях, отметили, что модели ИИ помогли как в обнаружении, так и в разработке эксплойта.

Исследователи сообщили об этих ошибках разработчикам PHP в августе 2026 года, в сентябре PHP начал работу над согласованным исправлением, а координированное раскрытие информации было назначено на 22 октября. Затем, 20 октября, идентификаторы CVE и детали эксплойтов утекли на Hacker News и в социальные сети. В тот же день PHP опубликовал предварительное уведомление и перенес релиз на один день раньше — на 21 октября, 14:00 по всемирному координированному времени (UTC).

Эксплуатация не стала дожидаться патча. Подразделение Amazon Threat Intelligence зафиксировало PHP2Shell attempt на свои ханепуты MadPot 17 октября, за четыре дня до раскрытия информации. Cloudflare сообщила о первых атаках 21 октября в 07:43 UTC, более чем за шесть часов до выпуска исправления. watchTowr воспроизвели ошибки и сообщили об активных попытках эксплуатации каждой из них.

Уязвимый код берет свое начало в PHP 5.4, выпущенном в 2012 году. Ошибки кроются в самом движке PHP, а не в каком-либо приложении. По этой причине любой сайт на WordPress, Drupal или Joomla с чистым кодом приложения остается уязвимым.

Чтобы предоставить дополнительные рекомендации командам безопасности и обеспечить обнаружение в режиме реального времени для пользователей Sysdig Secure и открытого проекта Falco, команда исследователей угроз Sysdig Threat Research Team (TRT) проанализировала эксплуатацию PHP2Shell. Выводы приведены ниже.

Затронутые версии PHP

Версия PHP

Статус

Что делать

5.4-7.3

Поддержка прекращена, исправления от проекта PHP отсутствуют.

Перейти на ветку с исправлениями.

7.4, 8.0, 8.1

Официальные обновления не выпускались. Команда безопасности PHP опубликовала лишь минимальные бэкпорты исходного кода для этих версий.

Использовать патченый дистрибутивный пакет от вендора или перейти на поддерживаемую ветку.

8.2, 8.3, 8.4, 8.5

Исправлено в ветках 8.2.35, 8.3.36, 8.4.27, 8.5.12

Обновиться до исправленного или более позднего релиза.

Помимо номера версии, при оценке потенциальной подверженности PHP2Shell следует учитывать еще три фактора:

• Дистрибутивные пакеты: Дистрибутивы Linux и поставщики релизов с долгосрочной поддержкой (LTS) получили патчи до релиза. Поставщики часто портируют исправления без изменения номера версии в upstream, поэтому проверяйте бюллетень вендора, а не только вывод команды php -v. Любой пакет, сообщающий о старой версии, должен быть пропатчен.
• Затронутые SAPI: Любая инсталляция PHP, обрабатывающая веб-запросы. Сюда входят Apache mod_php, PHP-FPM, php-cgi, FrankenPHP и LiteSpeed. PHP оценивает mod_php как наиболее рискованный вариант. SAPI — это то, как PHP подключается к веб-серверу, поэтому если PHP отвечает на HTTP-запросы в любой форме, он находится в зоне риска.
• Конфигурация по умолчанию: Уязвима. Для уязвимости не требуются какие-либо специфические настройки.

Первопричина

PHP-воркер повторно использует свою память от одного запроса к другому. Когда запрос превышает memory_limit, PHP сталкивается с фатальной ошибкой нехватки памяти (out-of-memory) и уничтожает кучу запроса (request heap). Воркер продолжает работать и переходит к следующему запросу.

Изъян заключается в том, что PHP не очищает глобальные указатели, ссылающиеся на кучу запроса, после фатальной ошибки нехватки памяти, поэтому последующий запрос на том же воркере использует устаревшие указатели на освобожденную память. Все четыре ошибки имеют эту общую первопричину.

CVE-2026-109618: Прогресс загрузки сеансов

• Use-after-free в десериализаторе. Функция прогресса загрузки сеансов декодирует данные сеанса во время разбора PHP multipart/form-data загрузки. Она хранит служебные данные в глобальном состоянии десериализатора. Ошибка нехватки памяти уничтожает кучу запроса, но это глобальное состояние остается опубликованным.
• Удаленное раскрытие памяти. Прогресс загрузки также сохраняет идентификатор сеанса (session ID) в глобальном указателе. Ошибка нехватки памяти может оставить этот указатель висячим (dangling). Последующий запрос multipart на том же воркере доходит до очистки прогресса загрузки до того, как инициализация сеанса сбросит указатель. Затем PHP кодирует в URL содержимое возвращенной в пул кучи, помещает его в ответный файл cookie PHPSESSID и отправляет клиенту.

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

CVE-2026-109619: Трассировка фатальной ошибки и OPcache

• Use-after-free в трассировках фатальных ошибок. PHP хранит трассировку последней фатальной ошибки в глобальной переменной. Ошибка нехватки памяти уничтожает кучу запроса, но не очищает эту глобальную переменную. Следующий запрос на воркере находит указатель на память предыдущего запроса.
• Нарушение типов в OPcache (type confusion). В то время как OPcache сохраняет скомпилированный скрипт в разделяемой памяти, сбой выделения памяти в неподходящий момент приводит к несогласованности внутренних слотов между воркерами. В результате один из воркеров интерпретирует данные с неправильным типом.

Воздействие

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

• Неаутентифицированное удаленное выполнение кода, учетные данные не требуются. Любой клиент, способный отправлять HTTP-запросы на уязвимый PHP-сервер, может запустить код от имени пользователя веб-сервера. Не требуется никаких входов в систему, ошибок в приложениях или действий пользователя.
• Подверженность любых PHP-приложений, а не только популярных или распространенных. Ошибки кроются в самом движке, поэтому даже самое минимальное приложение на уязвимой версии PHP может быть уязвимо.
• Утечка секретов из запросов других пользователей. Механизм раскрытия памяти работает сам по себе, даже без RCE. Он возвращает освобожденную память процесса неаутентифицированному клиенту. Эта память может содержать данные из других запросов, которые обрабатывал тот же воркер: учетные данные, токены сеансов, ключи API и даже закрытые ключи TLS.
• Компрометация контейнера и путь к хосту. PHP-контейнер — это типичная рабочая нагрузка, смотрящая в интернет. Выполнение кода в нем предоставляет злоумышленнику сервисный учетный пункт контейнера, смонтированные секреты и сетевое положение. Оттуда уязвимость повышения привилегий в ядре (LPE), такая как Copy Fail или Dirty Frag, может привести к компрометации хоста.

Обнаружение PHP2Shell с помощью Sysdig Secure

Клиенты Sysdig Secure, использующие управляемые политики, имеют в своем распоряжении средства обнаружения, помогающие выявлять эту активную угрозу и реагировать на нее. Команда Sysdig TRT уже опубликовала запись об угрозах (Threat Intelligence) для PHP2Shell в Sysdig Secure, а функция управления уязвимостями Sysdig обнаруживает уязвимые версии PHP в образах и на хостах. Существующие правила обнаружения во время выполнения также охватывают активность после эксплуатации.

Анализ угроз

У клиентов Sysdig Secure уже есть запись о PHP2Shell в ленте анализа угроз (Threat Intelligence feed). В записи кратко описаны сама уязвимость, исправленные версии и временные меры защиты. В ней также показано, сколько хостов и рабочих нагрузок в вашей среде затронуто. Нажмите на счетчик, чтобы открыть отфильтрованный поиск по уязвимому активу.

Управление уязвимостями

Управление уязвимостями Sysdig обнаруживает CVE-2026-109618 и CVE-2026-109619 в вашей среде:

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

Рантайм-обнаружение

Команда Sysdig TRT создала два многоуровневых правила рантайма для PHP2Shell и протестировала их на работающем эксплойте. Они поставляются в качестве управляемых правил в политиках Sysdig Runtime Behavioral Analytics и Sysdig Runtime Notable Events. Эти два правила: PHP Web Worker Killed by Fatal Signal и PHP Web Worker Crash Followed by Shell Execution.

Успешная атака PHP2Shell предоставляет злоумышленнику командную строку, после чего злоумышленники действуют так же, как и после любого другого RCE в веб. Они открывают обратную оболочку (reverse shell), скачивают и запускают утилиту, запускают майнер, крадут облачные учетные данные или пытаются использовать уязвимость LPE ядра для получения прав root. Sysdig Secure уже обнаруживает эту постэксплуатационную активность с помощью управляемых правил в политиках, которые включены по умолчанию. Большинство этих правил соответствуют поведению, а не родительскому процессу, поэтому они работают одинаково независимо от того, какая среда выполнения PHP обслуживает приложение.

Обнаружение PHP2Shell с помощью открытого ПО Falco

Falco видит системные вызовы, а не HTTP-запросы. Он не может видеть сам вредоносный запрос, но может видеть, к чему этот запрос приводит на хосте. Существует множество возможных стратегий обнаружения, например обнаружение процессов оболочки из воркеров php, но главной проблемой часто является шум. Как мы показывали ранее на примере Sysdig Secure, применимо множество существующих стратегий обнаружения постэксплуатации.

Рекомендации

• Обновите PHP на каждом сервере: перейдите на версии 8.5.12, 8.4.27, 8.3.36 или 8.2.35 либо на пропатченный вендором пакет. Это единственное полное исправление. Код приложения не может это исправить.
• Перезапустите каждый воркер PHP после установки патча: старые воркеры продолжают выполнять уязвимый код.
• Примите временные меры с помощью промежуточных настроек, если вы не можете установить патч сегодня: PHP заявляет, что эти настройки снижают риск, но не устраняют его: задайте memory_limit=-1 через php_admin_value, чтобы приложения не могли переопределить это значение. Вместо этого принудительно задайте лимиты размера запросов на веб-сервере или прокси. Не используйте RLIMIT_AS или RLIMIT_DATA. Установите session.upload_progress.enabled=0 в php.ini или в конфигурации пула FPM. Не полагайтесь на ini_set() или .user.ini. На PHP 8.5 также задайте fatal_error_backtraces=0. Перезапустите каждый воркер и проверьте значения через веб-запрос, а не через CLI.‍
• Задайте memory_limit=-1 через php_admin_value, чтобы приложения не могли переопределить это значение. Вместо этого принудительно задайте лимиты размера запросов на веб-сервере или прокси. Не используйте RLIMIT_AS или RLIMIT_DATA.
• Установите session.upload_progress.enabled=0 в php.ini или в конфигурации пула FPM. Не полагайтесь на ini_set() или .user.ini.
• На PHP 8.5 также задайте fatal_error_backtraces=0.
• Перезапустите каждый воркер и проверьте значения через веб-запрос, а не через CLI.‍
• Заблокируйте multipart/form-data на периметре, если загрузка файлов не требуется: это блокирует путь отслеживания прогресса загрузки сессии и раскрытие памяти. Это не решает проблему полностью для всех багов и нарушает работу загрузки файлов и некоторых форм оформления заказа.
• ‍Проведите аудит своей среды: найдите каждый затронутый хост и рабочую нагрузку, начиная с тех, которые имеют доступ в интернет. Клиенты Sysdig Secure могут использовать раздел Threat Intelligence и результаты Vulnerability Management. ‍
• Проведите расследование, начиная с 17 октября: эксплуатация началась до раскрытия информации. Проверьте систему на наличие веб-оболочек, новых заданий cron, новых учетных ролей и оболочек, порожденных процессами веб-сервера.‍
• Смените секретные данные: из-за раскрытия памяти секретные данные на подвергшихся воздействию серверах следует заменить, даже если вы не видите признаков выполнения кода.‍
• Включите политики рантайма по умолчанию: используйте средства обнаружения постэксплуатационного поведения, такие как известные угрозы, совпадения с данными аналитики угроз и поведенческие аномалии. Для общедоступных веб-приложений настройте оповещения об оболочках и подозрительных командах, порожденных веб-сервером. Политики Sysdig Runtime Threat Detection, Sysdig Runtime Threat Intelligence и Sysdig Runtime Behavioral Analytics отслеживают стадию постэксплуатации. Для общедоступного PHP клиентам также следует включить политику Sysdig Runtime Notable Events или, по крайней мере, ее правила для оболочек и подозрительных команд, порожденных веб-серверами.

Заключение

PHP2Shell состоит из четырех ошибок безопасности памяти в рамках двух критических CVE в ядре PHP, наиболее широко развернутой среды выполнения веб-приложений. Эксплуатация началась до появления исправления, и PHP содержал уязвимый код с 2012 года.

Это третья уязвимость с высокой степенью влияния в этом году в старом, широко используемом базовом коде после Copy Fail и Dirty Frag. Подобно тем уязвимостям, PHP2Shell была обнаружена с помощью искусственного интеллекта. Защитникам следует подходить к таким уязвимостям с позиции «предполагаемого взлома», поскольку эксплуатация может начаться до появления патча. Сначала установите патч. Затем, пока каждый воркер не будет пропатчен и перезапущен, используйте промежуточные настройки, фильтрацию на периметре и обнаружение в рантайме для устранения пробелов.