Две критические уязвимости в PHP были обнаружены в результате совместных усилий по исследованию безопасности, в которых участвовала инициатива Patch the Planet от . По данным OpenAI, исследователь под ником Calif изначально обнаружил уязвимости и координировал их раскрытие, а компания Wiz независимо обнаружила те же проблемы несколько недель спустя.

В течение последующих двух месяцев сопровождающие PHP провели координированную работу по раскрытию информации и устранению уязвимостей, причем OpenAI, Wiz, Cloudflare и другие партнеры по отрасли внесли свой вклад в исследования, техническую поддержку и координацию.

21 октября 2026 года проект PHP выпустил исправления для двух критических уязвимостей: CVE-2026-109618 и CVE-2026-109619. Обе имеют оценку 9.2 по шкале Common Vulnerability Scoring System (CVSS) v4 и могут позволить выполнить удаленный код без аутентификации (RCE), предоставляя злоумышленнику возможность запускать код на уязвимом сервере.

Эти недостатки затрагивают саму среду выполнения PHP, а не конкретное приложение, систему управления контентом или плагин. Один из них связан с повреждением памяти при обработке ситуаций нехватки памяти (out-of-memory); другой — с внутренним состоянием, которое остается доступным после освобождения памяти, стоявшей за ним. Пути их эксплуатации различаются, но оба требуют внимания к базовой среде выполнения.

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

Почему эти уязвимости заслуживают особого внимания

Средства контроля безопасности приложений могут не успеть среагировать. В PHP задокументирован вектор неаутентифицированной атаки против Apache mod_php, который срабатывает до того, как код приложения начинает выполняться. Аутентификация на уровне приложения не защищает этот вектор.
Уязвимость охватывает различные среды хостинга. Рекомендации PHP охватывают инсталляции, обрабатывающие веб-запросы, включая PHP-FPM, Apache mod_php, php-cgi, FrankenPHP и LiteSpeed. Организациям необходимо оценивать среду выполнения, а не только поддерживаемое ею приложение.
Условия эксплуатации не идентичны. Продемонстрированная уязвимость устаревшего состояния (stale-state) затрагивает различные запросы, обрабатываемые одним и тем же рабочим процессом (worker). Было бы неточным описывать обе уязвимости как универсально эксплуатируемые с помощью одного запроса.

Эти различия важны при оценке степени риска. Они должны определять вашу реакцию, а не становиться причиной отсрочки установки патчей.

Как мы реагируем в HackerOne

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

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

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

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

Как исследователи безопасности помогают организациям реагировать

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

Вот на чем должны сосредоточиться команды безопасности:

Усильте процесс раскрытия уязвимостей. Внимательно следите за поступающими отчетами и используйте автоматизацию для дедупликации, проверки и приоритизации находок на основе критичности активов и продемонстрированного воздействия. Не все уязвимости удаленного выполнения кода несут одинаковый риск в любой среде.
Используйте находки исследователей для определения приоритетов установки патчей. Применяйте патчи как можно быстрее, но при ограниченности ресурсов уязвимости, о которых сообщают извне и которые специфичны для вашей среды, могут помочь выявить наиболее срочные угрозы.
Смотрите дальше первоначального окна установки патчей. Крупные предприятия могли упустить из виду инсталляции PHP, которые остаются уязвимыми после первого раунда исправлений. Как только первоначальное патчение завершено, подумайте о том, чтобы стимулировать исследователей с помощью существующих программ bug bounty для выявления оставшихся уязвимостей.

Большее количество отчетов не обязательно означает больше успешных атак. Каждая находка требует проверки, чтобы отделить потенциально уязвимые активы от подтвержденных проблем безопасности.

HackerOne отслеживает соответствующую активность по отправке отчетов через Hacktivity, обеспечивая дополнительную прозрачность по мере продолжения координированного реагирования.

Координированное раскрытие: от обнаружения до защиты

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

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

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

HackerOne участвует в Patch the Planet, поддерживая более широкую миссию по превращению обнаруженных уязвимостей в действенные исправления посредством координированных исследований безопасности и раскрытия информации.

Этот урок выходит за рамки этих двух уязвимостей PHP: более быстрое обнаружение слабых мест в безопасности ценно, но защита организаций зависит от того, насколько эффективно сообщество безопасности может превратить эти открытия в исправления.

Неотложные действия для организаций, использующих PHP

Определите среды выполнения, от которых вы зависите. Включите инфраструктуру непосредственного управления, размещенные приложения, ресурсы хостинг-партнеров и аппаратные комплексы, поставляемые с PHP. Установите, кто несет ответственность за исправление каждого окружения.
Примените исправленный релиз для своей ветки PHP. Исправленными версиями являются PHP 8.2.35, 8.3.36, 8.4.27 и 8.5.12. Для упакованных или управляемых развертываний подтвердите, применил ли ваш поставщик аналогичное исправление безопасности.
Не упускайте из виду более старые инсталляции. PHP 8.1 и более ранние версии больше не получают регулярных обновлений от разработчиков. Некоторые вендоры предлагают бэкпортированные исправления, а команда безопасности PHP предоставила минимальные бэкпорты исходного кода для версий 7.4, 8.0 и 8.1. Проверьте покрытие вашего вендора или перейдите на поддерживаемый релиз.
Рассматривайте временные меры как временные. Следуйте официальному уведомлению безопасности PHP для получения применимых рекомендаций по снижению рисков при организации обновления. PHP прямо предупреждает, что эти меры не делают уязвимую инсталляцию безопасной.
Поддерживайте ясность каналов отчетности. Изучите область действия вашей программы и инструкции по отчетности, чтобы исследователи знали, куда отправлять соответствующие находки, а ваша команда понимала, как их расставлять по приоритетам.

Урок, извлеченный из этого релиза

Этот релиз объединяет четыре обязанности: понимание уязвимости, устранение собственного риска, осмысление поступающих находок и координация ответа.

Наш подход в HackerOne заключается в том, чтобы рассматривать эти обязанности как взаимосвязанные. Устранение уязвимостей решает лежащие в основе риски. Анализ отчетов помогает выявить находки, требующие внимания. Скоординированное раскрытие информации дает исследователям и организациям структурированный способ совместной работы над решением.

Помимо установки патчей, организации должны убедиться, что у них налажен надежный процесс скоординированного раскрытия информации, чтобы исследователи безопасности могли сообщать об уязвимостях, а команды — быстро проверять находки и принимать меры. H1 Response может помочь организациям управлять этим процессом.

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

Мы будем обновлять этот пост по мере развития ситуации.