Уязвимость в PHP — проблема не только сайтов, где администратор вручную установил PHP с php.net. Большинство сайтов используют пакеты Linux-дистрибутива, а значит, исправление для них зависит от того, когда его выпустит поставщик ОС. Пока пакет не обновлён, наличие исправленного релиза PHP само по себе не означает, что сервер защищён.
Повод говорить об этом сейчас — две уязвимости в ядре PHP с оценкой CVSS 9.4. SANS ISC повысил уровень тревоги до жёлтого: PHP широко распространён, а ранние PoC появились до выхода патча. В источнике также указано, что Cloudflare сообщает об эксплуатации уязвимостей в реальных атаках. Это не доказывает, что атакован конкретный сайт, но делает ожидание обновления без проверки рискованным.
Проблема касается владельцев сайтов и администраторов, которые не знают, откуда установлен PHP, или считают сам факт обновления версии достаточной проверкой. Признаки могут быть неочевидны: уязвимость находится в ядре, затрагивает стандартные установки и не обязательно проявляется как заметный сбой. Поэтому отсутствие ошибок в работе сайта не подтверждает безопасность.
В статье разберём, как устроены обе уязвимости, что известно о PoC и сообщениях об эксплуатации, почему сроки исправления зависят от дистрибутива и какие временные меры способны снизить риск. Отдельно обозначим ограничения этих мер: они не заменяют исправленный пакет, а некоторые могут нарушить загрузку файлов.
Две уязвимости затрагивают PHP начиная с версии 5
В бюллетене описаны две критические уязвимости: CVE-2026-109618 и CVE-2026-109619. Для них указана оценка CVSS 9.4. По данным источника, проблема затрагивает PHP начиная с версии 5, включая актуальные выпуски. Это широкий диапазон: риск касается не только серверов с самостоятельно собранным PHP, но и стандартных установок, если поставщик системы ещё не выпустил исправленный пакет.
Исправления выпущены для веток PHP 8
В PHP указаны исправленные выпуски 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Источник отдельно отмечает, что патч ожидается только для PHP 8. Поэтому наличие более старой ветки само по себе не означает, что для неё появится исправление от PHP: владельцу сайта важно ориентироваться на бюллетень поставщика операционной системы и его пакеты.
Номер версии PHP — не единственный критерий. Дистрибутив может перенести исправление в пакет со своей прежней версией, поэтому сравнение только с номерами выпусков PHP способно дать неверный вывод. Механика уязвимостей различается: одна связана с обработкой загрузок, другая — с состоянием PHP worker после ошибки запроса; подробности эксплуатации здесь не нужны, чтобы понять масштаб затронутых систем.
CVE-2026-109618: загрузка файлов может исчерпать память
Почему ограничение размера запроса не всегда срабатывает
Уязвимость затрагивает обработку загрузок через multipart/form-data. В обычном запросе PHP может сверить размер тела с post_max_size, но если запрос не содержит заголовок Content-Length, проверка не срабатывает ожидаемым образом. Сервер продолжает разбирать содержимое, хотя заданный лимит должен был ограничить объём POST-данных.
Риск создаёт не только общий размер тела. Вредоносный запрос может содержать множество заголовков частей и пустых файлов. Даже когда сами файлы не несут полезных данных, PHP должен обработать и представить в памяти структуру каждой части. Расход памяти растёт из-за метаданных и объектов загрузки, а не только из-за содержимого файлов. Поэтому проверка, ориентированная лишь на размер файла, не описывает весь риск.
Когда загрузка становится отказом в обслуживании
Если обработка запроса требует больше памяти, чем доступно процессу, PHP может исчерпать лимит памяти или ресурсы worker. Это способно нарушить обработку текущего запроса и повлиять на доступность сайта. Практический риск зависит от конфигурации PHP и веб-сервера, а также от того, сколько таких запросов сервер способен обрабатывать одновременно.
Ограничение post_max_size остаётся полезной настройкой, но само по себе не закрывает этот сценарий: проблема связана с запросом без Content-Length и стоимостью разбора множества частей. Уязвимость исправлена в обновлениях PHP; конкретная доступность исправления зависит от пакета, который поставляет дистрибутив.
CVE-2026-109619: сбой запроса оставляет состояние PHP worker
Ошибка запроса может пережить сам запрос
Уязвимость связана не с обычной обработкой файла, а с тем, как PHP завершает неудачный запрос и подготавливает worker к следующему. При определённой ошибке часть внутреннего состояния не сбрасывается полностью. Если при этом включены локальные настройки, PHP выдаёт предупреждение; в затронутом сценарии дальнейшая работа обращается к уже освобождённой памяти. Это use-after-free — ошибка управления памятью, способная привести к аварийному завершению процесса и, при подходящих условиях, к более серьёзным последствиям.
Риск зависит от конфигурации и поведения worker: сбой одного запроса не означает автоматически, что любой следующий запрос приведёт к эксплуатации. Но неполный сброс состояния важен именно потому, что долгоживущий процесс может обслуживать запросы последовательно. Ошибка, возникшая при обработке одного из них, способна повлиять на состояние процесса после его завершения.
Подтверждение для PHP 8.5
Источник сообщает о подтверждённой эксплуатации в PHP 8.5 при включённом fatal_error_backtraces. Это конкретное подтверждение для указанной версии и настройки, а не свидетельство, что уязвимость эксплуатируется одинаково на всех конфигурациях. Отключение этой опции само по себе не заменяет исправление: оно не устраняет дефект сброса состояния.
Для владельца сайта практический вывод — учитывать не только код ответа или факт завершения запроса, но и конфигурацию PHP, а также способ запуска worker. Механика отличается от CVE-2026-109618, связанной с расходом памяти при загрузке: здесь ключевой риск — сохранение некорректного состояния процесса после ошибки.
PoC уже опубликован, а сообщения об эксплуатации поступили от Cloudflare
Ранний PoC — не готовое подтверждение атаки
До выхода исправления появились ранние proof of concept. Один из опубликованных фрагментов содержит multipart-запрос с очень длинным именем файла. Это полезный индикатор: он показывает, на какой участок обработки запроса обращено внимание. Но сам по себе такой фрагмент не доказывает, что атака надёжно срабатывает на стандартной конфигурации или позволяет получить нужный атакующему результат. Ранние PoC могут быть неполными, зависеть от настроек PHP и не воспроизводить весь путь эксплуатации.
Поэтому наличие кода в открытом доступе означает, что детали уязвимостей уже обсуждаются и проверяются, но не позволяет автоматически оценить вероятность успешной атаки на конкретный сайт. Для этого важны версия и конфигурация PHP, а также то, какой именно сценарий демонстрирует PoC.
Cloudflare сообщила об эксплуатации в реальных атаках
Отдельно от ранних PoC стоит сообщение Cloudflare об эксплуатации уязвимости в реальных атаках. Это более весомый сигнал, чем публикация демонстрационного кода: речь идёт не только о теоретической возможности или лабораторной проверке. В источнике также указано подтверждение эксплуатации в PHP 8.5 при включённом fatal_error_backtraces. Это важная оговорка: подтверждённый сценарий связан с конкретной настройкой, а не доказывает одинаковую уязвимость всех установок.
Источник не приводит данных, позволяющих судить о масштабе атак или числе затронутых сайтов. Поэтому корректный вывод ограничен: эксплуатация подтверждена, но ранний PoC с длинным именем файла не следует считать самостоятельным доказательством успешной атаки. Уязвимости затрагивают обработку запросов PHP; детали их механики разобраны отдельно.
Патч PHP вышел, но рабочий срок обновления задаёт дистрибутив
Выпуск исправления PHP и его установка на сервере — разные события. Разработчики PHP публикуют исправленные исходные версии, но сайты часто используют не сборку с php.net, а пакеты, которые поставляет операционная система. Поэтому для администратора важна не только дата релиза PHP: исправление должно попасть в пакет его дистрибутива и быть установлено на сервере.
Поставщик может исправить старую ветку без смены версии
Дистрибутивы сопровождают собственные пакеты и могут переносить исправление в поддерживаемую ими версию PHP. Такой backport не обязательно меняет номер версии на тот, который указан в релизе PHP. Поэтому сравнение номера установленной версии со списком новых выпусков само по себе не показывает, устранена ли уязвимость.
В опубликованных данных указаны исправленные ветки PHP 8: 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Там же сообщается, что Ubuntu выпустила обновлённые пакеты для Ubuntu 22.04, 24.04, 26.04 и 26.10. Это подтверждает, что обновления поставщиков выходят отдельно от релиза PHP, но не означает, что пакет уже доступен для любой ОС или установлен на конкретном сервере.
Проверять нужно пакет, а не только номер PHP
Для систем с пакетным менеджером ориентир — бюллетень безопасности поставщика и состояние установленного пакета. В нём может быть указано исправление для версии PHP, которая выглядит старее перечисленных релизов: это не обязательно означает, что сервер уязвим, если поставщик перенёс патч. И наоборот, наличие новой версии в репозитории не защищает сайт, пока пакет не установлен и веб-сервер не использует обновлённую сборку.
Если PHP установлен вручную или поставляется отдельно от ОС, сроки и источник обновления будут другими. В таком случае нужно проверять канал, из которого администратор получает сборку, а не полагаться на бюллетень дистрибутива. Практическая гонка за исправлением начинается для каждого сервера тогда, когда его поставщик публикует подходящий пакет.
Временные меры снижают риск, но не заменяют исправление
Пока исправленный пакет ещё не доступен, можно уменьшить поверхность атаки. Но эти меры не устраняют дефект PHP: они лишь ограничивают отдельные пути к нему или сокращают возможный ущерб.
Отключение прогресса загрузки помогает не во всех случаях
Параметр session.upload_progress.enabled = Off отключает механизм отслеживания хода загрузки и может снизить риск, связанный с одной из уязвимостей. Это частичная мера: она не заменяет обновление и не закрывает все сценарии обработки запросов.
Ограничения запросов и WAF зависят от конфигурации
Лимиты на размер тела запроса полезны как общий барьер, но сами по себе не гарантируют защиты: уязвимый сценарий связан с обработкой multipart-запроса без Content-Length, поэтому важно проверить, как запрос проходит через прокси, веб-сервер и PHP. WAF может отфильтровать подозрительные запросы, если правило учитывает особенности атаки и не обходится на пути к приложению. Это дополнительный контроль, а не исправление кода.
Полная блокировка multipart/form-data жёстче, но имеет прямую цену: перестанут работать формы и функции, которые принимают файлы. Перед таким ограничением нужно проверить, какие загрузки использует сайт; иначе защитная мера нарушит штатную работу.
Сокрытие PHP не закрывает уязвимость
Удаление заголовка с версией PHP или смена расширения файла не меняют обработку запросов и не мешают атакующему обратиться к уязвимому коду. Такие действия могут скрыть часть сведений о сервере, но считать их защитой от этих уязвимостей нельзя. Временные ограничения стоит применять только как дополнение, пока поставщик системы не выпустит исправленный пакет.
Открытая веб-панель межсетевого экрана увеличивает риск
PHP встречается и в веб-интерфейсах сетевых устройств
PHP широко используется не только на обычных сайтах, но и в веб-интерфейсах продуктов на базе open-source firewall и router. Поэтому уязвимость PHP может затрагивать и панели администрирования таких устройств — если они используют уязвимую сборку и доступны для обработки запросов извне. Сам факт, что устройство является межсетевым экраном, не защищает его веб-приложение от ошибок в PHP.
Доступность панели меняет риск, но не устраняет уязвимость
В рекомендациях OPNSense и pfSense фигурируют обновления безопасности; Cisco и Palo Alto Networks также опубликовали материалы по уязвимостям. Это не означает, что уязвимы все продукты этих производителей или все установки firewall/router: важны конкретный продукт, его версия и пакет PHP. Проверять нужно бюллетень поставщика, а не делать вывод по одному лишь названию платформы.
Веб-администрирование не следует выставлять непосредственно в интернет. Если панель доступна только из доверенной сети или через защищённый канал управления, круг потенциальных источников запросов сужается. Но это мера снижения риска, а не исправление PHP: уязвимый компонент остаётся на устройстве и может быть доступен другим путём, например из внутренней сети. Закрытая панель также не заменяет установку исправленного пакета.
Для сетевого оборудования важно учитывать не только обновление самого firewall/router, но и то, как поставщик включает исправления PHP в свою сборку. Выпуск патча в PHP ещё не подтверждает, что он уже доступен для конкретного устройства. Ориентир — уведомление производителя и наличие обновлённой версии продукта; до этого ограничение доступа к веб-панели уменьшает поверхность атаки, но не делает уязвимую систему безопасной.
Проверка сайта начинается с версии PHP и источника пакетов
Проверять нужно не только номер PHP, но и то, откуда он установлен. Сайт может использовать PHP из репозитория операционной системы, отдельного репозитория или собственного окружения. Поэтому версия, показанная приложением, сама по себе не подтверждает, что исправление установлено.
Сначала определите, какой PHP обслуживает сайт
- Установите фактическую версию. Проверьте конфигурацию веб-сервера и PHP-FPM: версия в командной строке может относиться к другому исполняемому файлу, чем тот, который обрабатывает запросы сайта.
- Найдите источник пакета. Уточните, управляет ли PHP пакетный менеджер ОС или его установили отдельно. Для контейнера проверяйте образ и способ его сборки: обновление на хосте не обязательно меняет PHP внутри контейнера.
- Сверьте пакет с бюллетенем поставщика. Ищите исправление для своей системы и ветки PHP, а не только совпадение с номером upstream-релиза. Дистрибутив может перенести патч в пакет со старым номером версии; такой backport нужно подтверждать по уведомлению поставщика.
После обновления проверьте работающий процесс
Установите исправленный пакет штатным для этой системы способом и проверьте, что веб-сервер или PHP-FPM действительно использует обновлённую сборку. Если процессы продолжают работать со старым кодом, пакет на диске ещё не означает, что запросы уже обрабатываются исправленной версией. Перезапустите соответствующий сервис, когда этого требует поставщик, затем повторно проверьте версию и состояние пакета.
Если PHP собран вручную или поставляется вместе с приложением, бюллетень ОС может к нему не относиться: обновлять и подтверждать исправление нужно у источника этой сборки.
