21 октября разработчики и исследователи раскрыли две критические уязвимости в PHP — CVE-2026-109618 и CVE-2026-109619. Обе получили CVSS 9,2 и в худшем сценарии позволяют выполнить код на сервере без аутентификации, с правами веб-сервера.

Речь не о массовом «сломать всё одним запросом», а о сложной атаке, где злоумышленнику нужен удачный момент, утечка памяти и большой объём специально подготовленных HTTP-запросов. Но для владельцев сайтов это слабое утешение: если сервер уязвим, риск уже не теоретический.

Что произошло

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

Исследователи пишут, что уязвимости затрагивают PHP начиная с версии 5.4. В отчёте также отдельно отмечено, что часть цепочек эксплуатации связана с ошибками очистки памяти после OOM-ситуации — out-of-memory, то есть нехватки памяти во время обработки запроса.

По данным источника, патч получился очень большим — более 10 тысяч строк кода. Сам факт говорит о том, что проблема сидит глубоко, в базовых механизмах движка.

Как работает атака

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

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

Отдельно исследователи выделяют несколько путей атаки: через формы x-www-form-urlencoded, через отслеживание загрузки файлов и через отчёты о фатальных ошибках в PHP 8.5. Полный эксплойт, который доводит цепочку до выполнения вредоносного кода, пока известен только для варианта с PHP_SESSION_UPLOAD_PROGRESS.

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

Кого затронуло и какие последствия

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

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

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

Что делать сейчас

Первый и главный шаг — обновить PHP до исправленных версий: 8.2.35, 8.3.36, 8.4.27, 8.5.12 или более новых релизов из своей ветки. Если обновление откладывается, нужно хотя бы убрать самые опасные механизмы и ограничить входящий трафик на уровне веб-сервера или reverse proxy.

Временные меры не заменяют патч, но снижают риск. Для части сценариев помогает отключение session.upload_progress.enabled, а для PHP 8.5 — fatal_error_backtraces=0. Разработчики также советуют не полагаться только на внутренние лимиты PHP и ставить внешние ограничения памяти на уровне контейнера или cgroup.

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

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

Практический чек-лист

  • Обновите PHP до 8.2.35, 8.3.36, 8.4.27, 8.5.12 или новее.
  • Проверьте, не включён ли session.upload_progress.enabled.
  • Для PHP 8.5 отключите fatal_error_backtraces, если это допустимо в вашей среде.
  • Ограничьте размер и сложность запросов на веб-сервере или reverse proxy.
  • Убедитесь, что лимиты памяти и процессора заданы на уровне контейнера или cgroup.
  • Проверьте журналы на длинные и нетипичные запросы, а также аномальные значения сессий.
  • Пересмотрите настройки для публичных или удалённых рабочих мест, где администраторы заходят в панели управления.
  • Если патч пока невозможен, изолируйте уязвимый сервис от лишнего внешнего трафика и сократите поверхность атаки.
Поделиться: