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

Переводчик Google

Команда разработчиков 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 — сообщения об угрозе и рекомендациях специалистов по кибербезопасности.
 

Обновление: 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
 

Похожие темы

Назад
Сверху Снизу