Два связанных критических уязвимости удалённого выполнения кода

  • CVE-2026-109618 / GHSA-w8hw-w9fx-j79w: RCE через повреждение памяти из-за переполнения (OOM): Если запрос достигал лимита памяти PHP в точно неправильный момент, интерпретатор мог оставить частично инициализированные внутренние данные и позже трактовать их как корректные, что приводило к повреждению памяти. На Apache с mod_php неавторизованный запрос мог запустить это ещё до выполнения кода приложения, и удалённое выполнение кода было продемонстрировано с настройками по умолчанию. RCE также был подтверждён на PHP-FPM через пути кода уровня приложения.
  • CVE-2026-109619 / GHSA-6wmf-4rv5-p3rp: RCE через остаточное состояние: Фатальная ошибка в неправильный момент могла оставить внутреннее состояние указывающим на память, принадлежавшую предыдущему запросу. Позже последующий запрос, обработанный одним рабочим процессом, мог использовать эту освобождённую память. Было подтверждено использование освобождённой памяти и крах рабочего процесса, а автор отчёта продемонстрировал удалённое выполнение кода против реального приложения на Apache с mod_php.

Обе уязвимости находятся в частях PHP, которые затрагивают практически каждый запрос: управление памятью и обработка ошибок. Их центральное место в PHP — вот что делало обе уязвимости серьёзными, и одновременно настолько сложными для исправления без нарушения совместимости, снижения производительности или принуждения к изменениям в большой экосистеме сторонних расширений.

Первый внешний аудит и усиленный фокус на безопасность

В 2024 году PHP прошёл свой первый внешний аудит безопасности за долгие годы. PHP Foundation обеспечила финансирование от Sovereign Tech Agency для проведения аудита через OSTIF, и его выполняла компания Quarkslab. Во время работы над исправлением одной из найденных Quarkslab проблем разработчик ядра PHP, нанятый PHP Foundation, обнаружил первые признаки проблемы с OOM, стоящей за CVE-2026-109618. В 2024 году была выдвинута теория потенциального эксплуита для проблемы OOM, но конкретных путей не было найдено, а другие конкретные проблемы с явным воздействием отвлекали внимание.

Для исправления проблемы OOM команда безопасности PHP разработала несколько конкурирующих подходов, но каждый имел свои компромиссы: нарушение обратной совместимости, новый потенциал для атак отказа в обслуживании или необходимость изменений в многих сторонних расширениях, координация которых казалась невозможной. Команда безопасности PHP, работающая на основе консенсуса, испытывала трудности с выбором между этими вариантами и опасалась последствий неправильного выбора. В сочетании с отсутствием известного пути к удалённому выполнению кода и небольшой командой разработчиков ядра с необходимыми глубокими знаниями двигателя, занятых множеством ответственности, этот процесс принятия решений привёл к застою и многократным перезапускам работ на протяжении месяцев. Не будем скрывать: задержка была структурным отказом, вызванным как процессом принятия решений командой безопасности, так и недостатком ресурсов. Команда безопасности с тех пор начала менять свои процессы, и эта работа продолжается, чтобы решения принимались большинством и поощрялись компромиссы.

Построение устойчивой профессиональной организации безопасности

За последние месяцы способ организации работы по безопасности PHP значительно изменился. В мае 2026 года PHP Foundation создала Команду безопасности экосистемы, которая работает наряду с командой безопасности PHP над триажем, координацией и усилением защиты. Работа Volker Dusch в должности AI Security Engineer in Residence в PHP Foundation значительно улучшила коммуникацию и сотрудничество между командой безопасности PHP и Foundation. Alexandre Daubois присоединился к PHP Foundation в июле, чтобы помочь команде безопасности PHP в триаже, обработке и исправлении отчётов о безопасности, а Daniel Scherzer присоединился в сентябре для работы над усилением защиты.

Ранее в этом году была проведена работа с Alpha-Omega для сканирования PHP с использованием Claude Mythos от Anthropic. Но после сканирования Mythos были добавлены другие инструменты, включая Daybreak Red от OpenAI для валидации отчётов и эксплуитов, наряду с санитайзер-сборками и окружениями воспроизведения, которые соответствуют нашему CI на каждой платформе, которую поддерживает PHP.

PHP Foundation включила проект PHP в программу Patch the Planet, в рамках которой компания безопасности Calif начала аудит PHP 30 июля 2026 года. 11 августа исследователь Ryan A из Calif сообщил об условном удалённом выполнении кода с той же корневой причиной, что и проблема OOM, которую нашли в 2024 году. OpenAI независимо сообщила о той же корневой причине в тот же день, затем последовали дополнительные векторы атак от OpenAI 18 сентября и от Wiz 24 августа. Совсем недавно Trail of Bits также проводила аудит PHP. Отчёты от Calif, OpenAI и Wiz прояснили полное воздействие проблемы OOM, и с 11 августа исправление её стало главным приоритетом для всей команды PHP Foundation, занимающейся безопасностью. Без финансирования Foundation было бы невозможно иметь нескольких человек, работающих над этой проблемой полный рабочий день, в итоге на выходных и круглосуточно для координации и общения с другими вовлечённых сторонами.

Рост исследований с помощью ИИ также означает, что команда безопасности PHP получает гораздо больше отчётов, чем раньше. Как описал Alexandre Daubois на прошлой неделе в How the PHP Security Team Handles Your Reports, команда опубликовала 15 CVE с 1 июля и обработала более 100 отчётов, которые оказались неправомерными, дубликатами или невоспроизводимыми. ИИ помогает команде валидировать отчёты и группировать отчёты с одной и той же корневой причиной, но человек принимает каждое решение и работает над каждым патчем.

Утечка и нарушенное раскрытие уязвимости

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

Во вторник, 20 октября, примерно в 15:00 UTC, два идентификатора CVE начали циркулировать на интернет-форумах и в социальных сетях. Они сопровождались неправильным временем выпуска и неправильной оценкой CVSS 10.0 (фактическая оценка 9.2). Никаких технических деталей не просочилось. В ответ проект PHP переместил своё предварительное объявление и опубликовал его в 19:30 UTC. Он также переместил выпуск с 22 октября, 14:00 UTC, на 21 октября, 14:00 UTC. Дистрибьюторы всё ещё упаковывали исправление, поэтому немедленный выпуск оставил бы многих пользователей без лёгкого способа обновления. Перемещение выпуска на один день раньше было лучшим компромиссом между быстрым действием, предоставлением времени на подготовку людям и обеспечением простого пути обновления для всех, когда уязвимости были раскрыты.

В результате утечки и предварительного объявления около 20:00 UTC Calif, одна из компаний безопасности, сообщившая о проблемах, по ошибке опубликовала видео. Оно показало их proof of concept, работающий против ряда целей, и раскрыло несколько дополнительных, хотя и ограниченных, деталей об уязвимостях. Копии удалённого видео вскоре начали циркулировать в социальных сетях. Видео способствовало ускоренной разработке различных PoC (proof of concept эксплуитов), которые затем увеличили циркуляцию 21 октября.

Рекомендации по смягчению, которые мы начали предоставлять нескольким поставщикам критической инфраструктуры около 20 октября 23:00 UTC, возможно, также просочились. Команда безопасности PHP внимательно отслеживала и проверяла появляющиеся PoC после утечки, но не обнаружила функциональных эксплуитов на момент выпуска/публичного раскрытия.

21 октября в 07:41 UTC, более чем за шесть часов до координированного выпуска, Chainguard в одностороннем порядке нарушила embargo и опубликовала собранные образы, содержащие исправление. Как и другие дистрибьюторы, Chainguard получила патч заранее, чтобы его пользователи могли обновиться в момент раскрытия уязвимостей. Любой злоумышленник мог теперь изучить исправление в двоичной форме, пока все остальные пользователи PHP ждали выпуска. Это проигнорировало недели работы многих сторон по достижению координированного раскрытия.

Осторожный оптимизм на будущее

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

Мы уверены, что серьёзная уязвимость с исправлением, застрявшим на сложных компромиссах, теперь будет доведена до руководства PHP Foundation намного раньше, так как мы меняем процессы, чтобы руководство могло помочь направить ситуацию к своевременному разрешению. Мы сейчас приоритизируем меры для обеспечения того, чтобы уязвимости, требующие аналогично сложных исправлений, были разрешены быстрее, когда они будут сообщены в будущем. PHP Foundation и команда безопасности PHP многому научились за последние недели и будут работать, чтобы превратить свой опыт в долговечные повторяемые процессы.

Что мы просим у вас

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

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

Ключевая часть миссии PHP Foundation — расширить количество инженеров с глубоким знанием кодовой базы PHP и предоставить команде безопасности необходимые ресурсы. Мы можем достичь этой цели только с финансированием от тех, кто зависит от PHP:

  • Компании, которые строят продукты и сервисы на PHP: пожалуйста, спонсируйте PHP Foundation на уровне, который отражает, насколько вы на неё полагаетесь.
  • Провайдеры хостинга, облачные платформы и дистрибьюции, которые доставляют PHP миллионам пользователей.
  • Правительства и государственные учреждения, чьи сервисы работают на PHP. Финансирование немецким Sovereign Tech Agency аудита 2024 показывает, что может достичь государственное инвестирование, и нам нужно больше, на устойчивой основе.

Спонсирование PHP Foundation — это наиболее прямой способ обеспечить, что структурные проблемы вроде уязвимости OOM будут решены устойчиво, прежде чем они превратятся в чрезвычайные ситуации. Станьте спонсором на thephp.foundation/sponsor, и если ваша организация хотела бы поговорить о большей обязательности, свяжитесь с нами.

Спасибо

Спасибо команде безопасности PHP, волонтёрам и подрядчикам PHP Foundation, менеджерам выпуска и упаковщикам пакетов в дистрибьюциях и LTS поставщиках, которые сделали эти выпуски возможными. Спасибо Calif, особенно Ryan A, Wiz, OpenAI Codex Security, особенно Amy Burnett, OSTIF и Quarkslab за их исследования и ответственное раскрытие; Alpha-Omega, OpenAI и Anthropic за предоставление команде доступа к их инструментам и финансирование части работы по безопасности; Sovereign Tech Agency за финансирование аудита 2024; и всем нашим спонсорам, чья поддержка сделала эту работу возможной.