PHP на сайте: выполнение кода при нехватке памяти (CVE-2026-109618)
Дефект в самом PHP, поэтому он затрагивает разные CMS и самописные сайты на этой сборке, а не один продукт. Версии ниже 8.2.35, 8.3.36, 8.4.27 или 8.5.12 могли выполнить код, если запрос упирался в нехватку памяти. Обновите сборку: снятие memory_limit не заменяет патч.
Коротко о главном
- Чем опасно
- Посторонний запрос мог выполнить код в процессе PHP
- С чего начать защиту
- Обновите PHP своей ветки: 8.2 до 8.2.35, 8.3 до 8.3.36, 8.4 до 8.4.27, 8.5 до 8.5.12 или новее.
- Как подтвердить
- Внешняя проверка может заметить признак этого дефекта: обработка запроса на сайте обрывается. Это не доказывает выполнение кода и не заменяет сверку версии PHP на сервере.
- Продукт
- PHP
- Оценка риска
- CVSS 9.8 / 10
Как проверить и что учитывать
Внешняя проверка может заметить признак этого дефекта: обработка запроса на сайте обрывается. Это не доказывает выполнение кода и не заменяет сверку версии PHP на сервере. Не делайте вывод о наличии уязвимости только по одному внешнему признаку: подтвердите результат в настройках и версии компонента.
Что нужно для подтверждения
Проверка смотрит публичный признак сбоя. Номер сборки и способ запуска PHP по-прежнему подтверждает администратор.
Ограничения вывода
- Сайт за фильтром запросов или без mod_php может не показать признак, даже если сборка уязвима.
- Признак не отличает CVE-2026-109618 от соседнего дефекта той же обработки памяти.
- Запись KEV принадлежит VulnCheck, это не каталог CISA.
Что произошло
PHP выходил из обработки запроса через longjmp, когда кончалась память. Если это случалось до полной подготовки запроса, завершение могло использовать неинициализированную память и выполнить код.
Бюллетень PHP от 21 октября 2026 года прямо говорит, что полное исправление одно: сборка с патчем. Снятие memory_limit только убирает удобный способ упереться в лимит.
Кого это касается
Это ошибка языка PHP, а не плагина одной CMS. На одной и той же сборке могут работать WordPress, 1С-Битрикс, Joomla, Drupal, MODX, OpenCart и самописный сайт. Узнали свой движок — проверяйте версию PHP, а не только обновления CMS. Затронуты ветки ниже 8.2.35, 8.3.36, 8.4.27 и 8.5.12.
Подтверждённый сценарий без кода приложения описан для Apache с модулем PHP. Для PHP-FPM проект тоже считает риск возможным, но готовый сценарий для него не показан. Запись об атаках есть у VulnCheck, в каталоге CISA её нет.
| Ветка | Исправление |
|---|---|
| 8.2 | 8.2.35 |
| 8.3 | 8.3.36 |
| 8.4 | 8.4.27 |
| 8.5 | 8.5.12 |
Как проверить установленную версию
Смотрите версию в командной строке на своём сервере или в панели хостинга. Не публикуйте phpinfo.
php -vКак снизить риск
Поставьте исправление и перезапустите PHP. Ограничение размера запроса на веб-сервере полезно и после патча, но само по себе дефект не закрывает.
Бесплатная внешняя проверка домена может показать только признак сбоя. Установленную версию PHP всё равно сверяют на сервере.
Что может произойти
- Посторонний запрос мог выполнить код в процессе PHP
- Под угрозой сайты на mod_php и похожих схемах, где обработка запроса не прерывается при сбое старта
- Отключение лимита памяти не считается полным исправлением
Как защититься
- 1Обновите PHP своей ветки: 8.2 до 8.2.35, 8.3 до 8.3.36, 8.4 до 8.4.27, 8.5 до 8.5.12 или новее.
- 2Перезапустите воркеры PHP после обновления и проверьте, что панель хостинга не откатила версию.
- 3Пока обновление невозможно, снимите конечный memory_limit только как временную меру и ограничьте размер разобранного запроса на фронте. Это не закрывает дефект полностью.
Как проходит проверка
Внешняя проверка может заметить признак этого дефекта: обработка запроса на сайте обрывается. Это не доказывает выполнение кода и не заменяет сверку версии PHP на сервере. Автоматический результат показывает внешний признак риска и требует проверки специалистом с учётом конкретной конфигурации.
Проверить свой сайтЧто делать после обнаружения
- Зафиксируйте версию PHP и способ запуска: mod_php, FPM или другой.
- Если сервер уже принимал запросы на уязвимой сборке, проверьте новые файлы в каталоге сайта и задания планировщика.
- Попросите хостинг подтвердить версию письменно, если панель её не показывает.
Частые вопросы
Что означает риск «PHP: выполнение кода при нехватке памяти»?
Дефект в самом PHP, поэтому он затрагивает разные CMS и самописные сайты на этой сборке, а не один продукт. Версии ниже 8.2.35, 8.3.36, 8.4.27 или 8.5.12 могли выполнить код, если запрос упирался в нехватку памяти. Обновите сборку: снятие memory_limit не заменяет патч.
Можно ли подтвердить проблему только внешней проверкой?
Внешняя проверка может заметить признак этого дефекта: обработка запроса на сайте обрывается. Это не доказывает выполнение кода и не заменяет сверку версии PHP на сервере. Итог нужно сопоставить с конфигурацией, версиями и правами доступа на вашем сайте.
Что сделать в первую очередь?
Обновите PHP своей ветки: 8.2 до 8.2.35, 8.3 до 8.3.36, 8.4 до 8.4.27, 8.5 до 8.5.12 или новее.