Критические уязвимости PHP позволяют выполнять код на сервере: готовятся экстренные исправления

Команда разработчиков PHP готовит экстренное обновление безопасности для устранения двух критических уязвимостей — CVE-2026-109618 и CVE-2026-109619. Обе получили оценку 9,2 из 10 по шкале CVSS v4.0. По сообщениям исследователей безопасности, уязвимости могут позволить удалённое выполнение произвольного кода (RCE), а сведения об их эксплуатации уже появились в открытых источниках.

Выпуск исправлений запланирован на 21 октября 2026 года, 14:00 UTC (17:00 по Киеву). Команда PHP предупредила, что может выпустить обновление раньше, если появятся публичные технические подробности или подтверждения активной эксплуатации. Полная информация о затронутых версиях и исправленных сборках должна быть опубликована вместе с обновлением.

По предварительным оценкам CERT-EU, уязвимости могут затрагивать все версии PHP начиная с ветки 5.x. При этом точный перечень уязвимых версий и технические подробности на момент подготовки материала ещё не были официально раскрыты.

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

Что делать администраторам​

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

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

2. При невозможности обновления ограничить публичный доступ.
Если установить исправление сразу не получается, наиболее надёжная временная мера — изолировать уязвимые приложения от публичного интернета до установки патча. В зависимости от назначения сервиса можно использовать VPN, ограничения по IP-адресам или другие сетевые средства контроля доступа.

Особое внимание следует уделить приложениям на неподдерживаемых версиях PHP, для которых исправления могут быть недоступны.

3. Использовать WAF как дополнительный уровень защиты.
Web Application Firewall (WAF) способен отфильтровывать часть вредоносных запросов и снизить риск эксплуатации уязвимости. Если поставщик используемого WAF выпускает соответствующие правила защиты, их стоит применить и проверить журналы блокировок.

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

4. Не полагаться на изменение session.upload_progress.enabled.
В первоначальных обсуждениях предлагалось отключить параметр session.upload_progress.enabled в конфигурации PHP. Однако более поздние сведения указывают, что изменение этой настройки не защищает от рассматриваемых уязвимостей. Использовать его как способ устранения проблемы не следует.

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

Обновление откладывать не стоит​

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

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

Источники для редакционной проверки:​

• Официальный анонс PHP — сроки выпуска и оценка критичности.
• CERT-EU — рекомендации по срочному обновлению и временной изоляции приложений.
• Aikido Security — сведения об эксплуатации и уточнение по неэффективности ранее предложенных конфигурационных мер.
• Reuters — сообщения об угрозе и рекомендациях специалистов по кибербезопасности.

 

[akok]

Обновление: PHP выпустил исправления критических уязвимостей CVE-2026-109618 и CVE-2026-109619​

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

Исправленные версии PHP:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

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

Что исправлено​

• CVE-2026-109618 — ошибка обработки нехватки памяти (OOM), из-за которой PHP может обратиться к частично инициализированным внутренним данным. При определённых условиях это позволяет добиться удалённого выполнения кода.
• CVE-2026-109619 — использование устаревшего внутреннего состояния после освобождения памяти. Повторное использование рабочего процесса может привести к обращению к некорректным данным и выполнению кода.

Технические подробности опубликованы в официальных уведомлениях: CVE-2026-109618 и CVE-2026-109619.

Если обновить PHP немедленно невозможно​

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

Для CVE-2026-109618:

• Рассмотреть установку memory_limit = -1 на уровне конфигурации FPM-пула или Apache, чтобы приложение не могло переопределить значение. Это снижает риск эксплуатации через контролируемое исчерпание лимита памяти PHP, но не устраняет все сценарии OOM.
• Ограничить размер POST-запросов: post_max_size = 8M, если загрузка файлов не требуется, или post_max_size = 32M, если она необходима. upload_max_filesize должен быть меньше post_max_size.
• Дополнительно ограничить размеры и структуру запросов на уровне веб-сервера или прокси. Для изоляции последствий исчерпания ресурсов можно использовать контейнеры или cgroups.

Для CVE-2026-109619:

• Установить session.upload_progress.enabled = Off в php.ini, конфигурации FPM-пула или сервера и перезапустить все рабочие процессы PHP. Настройка должна применяться до разбора запроса; ini_set() и .user.ini для этой меры не подходят.
• На PHP 8.5 дополнительно установить fatal_error_backtraces = 0 и перезапустить рабочие процессы. Это блокирует только подтверждённый сценарий эксплуатации через трассировку стека при фатальной ошибке.
• Проверить обработчики загрузки и импорта файлов, обратные вызовы, тайм-ауты и очистку данных, которые могут приводить к фатальным ошибкам.

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

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

Что делать с PHP 8.1 и более старыми версиями​

PHP 8.1 и более старые ветки больше не получают обычные обновления безопасности от основного проекта. Для PHP 7.4, 8.0 и 8.1 разработчики подготовили отдельные минимальные исправления в исходном коде. Кроме того, некоторые дистрибутивы Linux и поставщики LTS могут выпускать собственные исправленные пакеты.

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

Главное: проверьте используемую версию PHP и установите исправление как можно скорее. Обновление CMS или её плагинов само по себе проблему не устраняет.

Официальное уведомление: PHP: News Archive - 2026

 

[akok]

PHP Foundation раскрыла подробности двух критических RCE-уязвимостей и объяснила задержку с исправлениями​

21 октября 2026 года разработчики PHP выпустили обновления безопасности PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35, устраняющие две критические уязвимости, которые при определённых условиях позволяют удалённому злоумышленнику выполнять произвольный код на сервере без аутентификации.

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

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

Обновления устраняют две связанные проблемы безопасности, затрагивающие внутренние механизмы PHP.

CVE-2026-109618 — удалённое выполнение кода из-за повреждения памяти при её исчерпании (OOM)

Если запрос достигал ограничения memory_limit в определённый момент выполнения, PHP мог оставить частично инициализированные внутренние структуры данных, которые впоследствии воспринимались как корректные. Это приводило к повреждению памяти.

В конфигурации Apache с mod_php неаутентифицированный запрос мог вызвать уязвимость ещё до выполнения кода приложения. Исследователи продемонстрировали полноценное удалённое выполнение кода при настройках по умолчанию.

Возможность удалённого выполнения кода также была подтверждена для PHP-FPM через пути выполнения, зависящие от кода приложения.

Идентификаторы: CVE-2026-109618, GHSA-w8hw-w9fx-j79w.

CVE-2026-109619 — удалённое выполнение кода из-за некорректного сохранения глобального состояния

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

Следующий запрос, обработанный тем же рабочим процессом, мог обратиться к уже освобождённой памяти. Исследователи подтвердили ошибку типа use-after-free и аварийное завершение рабочего процесса.

Автор отчёта также продемонстрировал удалённое выполнение кода в реальном приложении, работавшем на Apache с mod_php.

Идентификаторы: CVE-2026-109619, GHSA-6wmf-4rv5-p3rp.

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

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

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

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

Во время исправления одной из обнаруженных Quarkslab проблем разработчик ядра PHP, работавший по контракту с PHP Foundation, заметил первые признаки ошибки обработки нехватки памяти, впоследствии получившей идентификатор CVE-2026-109618.

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

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

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

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

В результате работа над исправлением неоднократно останавливалась и возобновлялась на протяжении нескольких месяцев.

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

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

Создание устойчивой профессиональной команды безопасности​

За последние месяцы организация работы над безопасностью PHP существенно изменилась.

В мае 2026 года PHP Foundation создала Ecosystem Security Team — команду, которая совместно с основной командой безопасности занимается первичной обработкой отчётов, координацией исправлений и усилением защищённости проекта.

Работа Фолькера Душа (Volker Dusch) в качестве AI Security Engineer in Residence значительно улучшила взаимодействие между PHP Foundation и командой безопасности.

В июле к Foundation присоединился Александр Добуа (Alexandre Daubois), чтобы помогать с анализом, обработкой и исправлением отчётов об уязвимостях. В сентябре к команде присоединился Даниэль Шерцер (Daniel Scherzer), занявшийся повышением защищённости PHP.

В начале года PHP Foundation совместно с Alpha-Omega провела анализ PHP с использованием модели Anthropic Claude Mythos.

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

PHP Foundation также добилась включения проекта в программу Patch the Planet.

В рамках этой программы 30 июля 2026 года компания Calif начала аудит безопасности PHP.

11 августа исследователь Ryan A из Calif сообщил об уязвимости, позволяющей без дополнительных условий выполнять произвольный код удалённо. Она имела ту же первопричину, что и OOM-проблема, обнаруженная ещё в 2024 году.

В тот же день OpenAI независимо сообщила об этой же первопричине.

Позднее поступили дополнительные сведения о способах эксплуатации:

• 24 августа — от компании Wiz;
• 18 сентября — от OpenAI.

В последнее время аудитом PHP также занималась Trail of Bits.

Отчёты Calif, OpenAI и Wiz позволили окончательно оценить масштаб и опасность OOM-проблемы.

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

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

Как искусственный интеллект повлиял на поиск уязвимостей​

Распространение исследований с использованием ИИ привело к резкому увеличению количества поступающих отчётов о потенциальных уязвимостях.

По словам Александра Добуа, с 1 июля команда PHP опубликовала сведения о 15 CVE и обработала более 100 отчётов, которые оказались ошибочными, дублирующими друг друга или невоспроизводимыми.

ИИ помогает проверять поступающие сообщения и группировать отчёты, имеющие общую первопричину.

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

Утечка информации нарушила согласованное раскрытие уязвимостей​

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

20 октября примерно в 15:00 UTC идентификаторы двух CVE начали распространяться на форумах и в социальных сетях.

При этом публикации содержали неверное время выхода обновлений и ошибочную оценку критичности CVSS 10.0. Фактическая оценка составляла 9,2 балла.

Технические подробности уязвимостей на тот момент не утекли.

В ответ разработчики PHP перенесли предварительное объявление на более раннее время и опубликовали его 20 октября в 19:30 UTC.

Также был изменён график выпуска исправлений: вместо 22 октября в 14:00 UTC обновления решили выпустить 21 октября в 14:00 UTC.

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

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

Преждевременная публикация демонстрации эксплойта​

После утечки и предварительного объявления, состоявшегося около 20:00 UTC, компания Calif, одна из организаций, сообщивших об уязвимостях, по ошибке опубликовала видеозапись.

На видео демонстрировалась работа proof-of-concept-эксплойта против нескольких целей, а также раскрывались некоторые дополнительные, хотя и ограниченные, технические подробности.

Видео вскоре удалили, однако его копии уже начали распространяться в социальных сетях.

По оценке PHP Foundation, публикация способствовала ускоренной разработке различных PoC-эксплойтов, которые 21 октября стали распространяться ещё активнее.

Не исключается и утечка рекомендаций по временному снижению рисков, которые команда начала предоставлять отдельным операторам критической инфраструктуры около 23:00 UTC 20 октября.

После этих событий специалисты PHP внимательно отслеживали и анализировали появлявшиеся PoC.

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

Chainguard нарушила эмбарго на публикацию исправлений​

21 октября в 07:41 UTC, более чем за шесть часов до согласованного выпуска, компания Chainguard самостоятельно нарушила эмбарго и опубликовала готовые образы, содержащие исправления.

Как и другие поставщики дистрибутивов, Chainguard заранее получила патчи, чтобы её пользователи могли обновиться сразу после официального раскрытия информации.

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

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

Осторожный оптимизм относительно будущего безопасности PHP​

По мнению PHP Foundation, выпуск обновлений демонстрирует прогресс в организации работы над безопасностью проекта.

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

Дистрибутивы и поставщики версий с долгосрочной поддержкой заранее получили патчи, чтобы пользователи могли оперативно обновить свои системы.

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

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

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

Почему PHP Foundation необходима дополнительная поддержка​

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

При этом безопасность самого PHP по-прежнему зависит от небольшой группы разработч