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

Релиз от 21 октября устраняет уязвимости CVE-2026-109618 и CVE-2026-109619. Администраторам Linux и хостинг-провайдерам необходимо обновить сам PHP, перезапустить затронутые службы и убедиться, что их сайты используют исправленную версию. Риск выходит за рамки Apache, хотя условия для проведения атаки различаются в зависимости от конфигурации сервера.


 Какие веб-сайты находятся в зоне риска? 

Любой веб-сайт, работающий на уязвимой версии PHP, требует внимания. Предупреждение PHP охватывает Apache с  mod_php ,  PHP-FPM ,  php-cgi ,  FrankenPHP  и  LiteSpeed . Это различные способы запуска PHP — ПО, на котором работают такие приложения, как WordPress. Выбор того или иного варианта настройки сервера не отменяет необходимости проверки наличия обновлений.

lPpHMsbOkvqEjeZVpUHTK0ac2VEhv2GQR8j645kH.webpВ бюллетене безопасности PHP перечислены уязвимые конфигурации веб-сервера, включая Apache mod_php, PHP-FPM, php-cgi, FrankenPHP и LiteSpeed. Источник: бюллетень безопасности PHP.net, 21 октября 2026 г. 

Наиболее наглядно продемонстрированная атака направлена на Apache  mod_php , который выполняет PHP внутри веб-сервера. Специально сформированный веб-запрос может эксплуатировать уязвимость ещё до запуска собственного кода сайта. Это означает, что форма входа на сайт не сможет предотвратить такую атаку. Злоумышленник получит права учётной записи, от имени которой обрабатываются веб-запросы, но не автоматически полный доступ администратора.

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


 Что изменилось в экстренном обновлении PHP? 

PHP выпустила версии 8.5.12, 8.4.27, 8.3.36 и 8.2.35 для устранения эти проблем. Обе уязвимости связаны с тем, как PHP обрабатывает память и ошибки при обработке веб-запросов. Они затрагивают сам движок, исполняющий веб-сайт, поэтому обновление темы, плагина или системы управления контентом (CMS) не исправит проблему.

WVKRG3A3E2X0xLLPFfXokHUd9kweMirePKVqmvRg.webpВ бюллетене PHP о повреждении памяти при OOM переведены затронутые ветки и четыре патченных апстрим-релиза. Источник: бюллетень безопасности PHP GHSA-w8hw-w9fx-j79w 

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

Апстрим-бюллетень по OOM-состоянию (где OOM означает нехватку памяти) и бюллетень по персистентному состоянию объясняют протестированные векторы атак. Для владельцев веб-сайтов первостепенный вопрос прост: установил ли хостинг-провайдер исправление для PHP или только обновил файлы самого сайта?

Статья LinuxSecurity Effective Strategies to Secure PHP on Linux Web Servers for Safety описывает комплексный подход к обеспечению безопасности PHP-сайта. Эти регулярные проверки по-прежнему важны, однако текущий релиз требует отдельного обновления самого интерпретатора.


 Red Hat призывает клиентов установить патчи вне плановых окон 

В заявлении от 21 октября компания Red Hat сообщила, что участвовала в процессе согласованного раскрытия информации и работала над исправлениями и мерами защиты ещё до того, как уязвимости стали публичными. Её страницы для CVE-2026-109618 и CVE-2026-109619 содержат рекомендации для продуктов Red Hat.

«Учитывая потенциальное влияние этих уязвимостей, Red Hat рекомендует клиентам развернуть проверенные и протестированные патчи сразу после их появления из надёжных источников, включая Red Hat, даже за пределами стандартных окон обслуживания», — заявил в обращении Гуннар Хеллегсон (Gunnar Hellekson), вице-президент и генеральный менеджер направления Lightwell в Red Hat.

Red Hat оценивает уязвимости как «Important» (важные) для своих продуктов и отмечает, что стандартные развертывания Red Hat Enterprise Linux используют  PHP-FPM . Эта специфика оценки продукта отличается от критического рейтинга, присвоенного разработчиками PHP. Клиентам следует руководствоваться рекомендациями для их установленных пакетов при организации обновления.


 Что необходимо сделать сисадминам Linux прямо сейчас 

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

Установите исправленный пакет от поставщика, отвечающего за данную сборку. Дистрибутивы Linux часто бэкпортируют исправления, добавляя их в более старые релизы без перехода на последнюю апстрим-версию. Трекеры Ubuntu и уведомление об обновлении PHP в Ubuntu содержат список соответствующих пакетов; обновление Debian PHP 8.2 содержит нужный пакет для пользователей Debian 12. Debian также отслеживает статус уязвимости во всех своих релизах.

VlavgTFKlcQLyiqWoNgZHxrh3DFm3TWrzAsVMssd.webpВ бюллетене безопасности PHP от Ubuntu перечислены версии исправленных пакетов для Ubuntu 24.04 LTS и 22.04 LTS. Источник: бюллетень безопасности Ubuntu USN-8948-1

После установки пакетов перезапустите затронутые службы Apache или PHP-FPM, следуя инструкциям вендора. Замена файлов на диске может оставить старый код выполняющимся в уже запущенном процессе. Убедитесь, что исправленный пакет активен, затем проверьте стандартные функции сайта, такие как авторизация и загрузка файлов. В статье Linux Patching Best Practices: Designing a Patch Validation Workflow описан более широкий процесс валидации обновлений.

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

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


 Утечка ускорила выход релиза 

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

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

Предыдущие проблемы с PHP, описанные в статье PHP: Critical Updates For Information Exposure And Code Execution Risks, также требовали вмешательства на уровне ниже приложения. Главное действие для защиты от данных уязвимостей PHP — убедиться, что каждый сайт работает на обновлённом интерпретаторе, даже если плагины и код самого приложения уже актуальны.


 Вопросы об уязвимостях PHP 

Исправляет ли обновление WordPress эти уязвимости PHP?

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

Затронут ли PHP-FPM?

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

Какие версии PHP содержат исправления?

Исправленные апстрим-релизы — это PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Пакеты дистрибутивов могут иметь другие номера версий, так как вендоры бэкпортируют исправления; ориентируйтесь на полную версию пакета из уведомления вашего поставщика.

Получайте больше оригинальных исследований по безопасности Linux, подписавшись на рассылку LinuxSecurity.