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

21 октября 2026 года команда PHP выпустила внеплановые обновления, а Европейская группа реагирования на киберинциденты CERT-EU опубликовала экстренное предупреждение. Обе уязвимости оценены в 9,2 балла и дают выполнить произвольный код на сервере без аутентификации.

Поскольку PHP остаётся самым распространённым языком серверной части веба — на нём работают WordPress, Joomla, OpenCart, Bitrix, Laravel и значительный объём самодельных интеграций с CRM и учётными системами, — круг затронутых систем охватывает большинство организаций с собственным веб-ресурсом, включая научные и аналитические учреждения.

Что именно нашли

Уязвимостей две, обе оценены в 9,2 балла и обе ведут к одному результату — выполнению чужого кода на сервере без авторизации.

CVE-2026-109618 — срыв при нехватке памяти

В PHP есть настройка memory_limit: запрос, съевший слишком много памяти, обрывается принудительно. Проблема в том, как именно он обрывается. PHP может прерваться в момент, когда внутренние данные запроса заполнены лишь наполовину — например, пока разбирается файл, присланный через форму загрузки. Уборка после такого запроса принимает недоделанные данные за настоящие и пытается освободить память, которой никогда не было. А в той памяти может лежать то, что атакующий положил туда предыдущими запросами.

CVE-2026-109619 — остатки предыдущего запроса

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

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

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

Какие версии под угрозой

Всё, что ниже этих версий, — уязвимо:

Ветка PHP	Безопасная версия
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35
PHP 8.1 и старше	поддержки нет

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

Оценка риска для учреждений

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

Для научных и аналитических учреждений к типичным последствиям (размещение веб-шелла, рассылка спама, попадание домена в чёрные списки, потеря почтовой доставки) добавляются два специфических. Первое — целостность данных: массивы исследований, нормативные документы и результаты опросов, размещённые на том же сервере, становятся доступными для изменения, а подмену цифр в публикации обнаруживают с большим запозданием. Второе — репутационное: материал, опубликованный от имени учреждения, воспринимается как его официальная позиция.

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

Что делать — пошагово

1. Узнайте свою версию. В панели хостинга это раздел «Версия PHP» или «PHP Selector»; на собственном сервере — команда php -v. Важно проверить версию, на которой работает именно сайт, а не ту, что стоит в командной строке: они часто разные.
2. Обновитесь в пределах своей ветки. Переход с 8.2.29 на 8.2.35 — это исправление внутри одной ветки: совместимость сохраняется, сайт от этого не ломается. Не путайте с переходом с 8.2 на 8.4 — вот он уже требует проверки.
3. Если у вас 8.1 или старше — поддержки этих ветвей нет. Из-за серьёзности ситуации команда безопасности PHP выпустила минимальные исправления и для 7.4, 8.0 и 8.1, а часть хостеров держит собственные сборки. Но правильное решение — переезд на поддерживаемую ветку, и планировать его лучше сейчас, а не в следующий раз.
4. Перезапустите обработчики. Без перезапуска php-fpm или Apache рабочие процессы продолжают работать на старом коде, и обновление фактически не действует.
5. Проверьте результат. Проще всего — временная страница с phpinfo(), которую сразу после проверки нужно удалить, либо же раздел «Версия PHP» в панели после перезагрузки.

Пользователям хостинга чаще всего ничего делать руками не придётся: крупные провайдеры получили исправления заранее и обновляют свои машины сами. Стоит написать в поддержку одну строку — «обновлён ли PHP до версий от 21 октября 2026» — и получить ответ письменно.

Если обновить прямо сейчас не получается

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

• запретить переполнение памяти как точку входа: memory_limit=-1, заданный так, чтобы приложение не могло это переопределить, и проверка, что ни один пул или каталог не возвращает лимит назад;
• уменьшить post_max_size — 8M для сайтов без загрузки файлов, 32M если загрузки нужны, а upload_max_filesize держать ниже;
• выключить session.upload_progress.enabled и перезапустить все рабочие процессы;
• на PHP 8.5 дополнительно выключить fatal_error_backtraces;
• ограничить размер и сложность запросов на уровне веб-сервера или прокси.

Ни одна из этих мер не делает установку безопасной. Они лишь перекрывают известные пути — полностью проблему закрывает только обновление.

Если и это невозможно, CERT-EU советует простое и непопулярное решение: убрать уязвимый сервис из публичного интернета, пока исправление не будет установлено и проверено.

Откуда эти данные

• CERT-EU, Security Advisory 2026-018 «Critical Vulnerabilities in PHP»
• Объявление о выпуске обновлений на php.net
• Техническое описание CVE-2026-109618 и CVE-2026-109619

---

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

Автор материала — SmartGT. Первоисточник: «Критические уязвимости PHP: обновление нельзя откладывать».