PHP под прицелом: критические RCE CVE-2026-109618 и CVE-2026-109619

Две уязвимости в PHP с оценкой 9.2 по CVSS 4.0 позволяют неаутентифицированному атакующему выполнить код на сервере. Разбираем механизм longjmp(), масштаб экспозиции и порядок действий.

21 октября 2026 года Национальный центр кибербезопасности Великобритании (NCSC) выпустил экстренное предупреждение: в PHP — языке, на котором работает значительная часть интернета, — обнаружены две критические уязвимости, CVE-2026-109618 и CVE-2026-109619. Обе позволяют неаутентифицированному атакующему выполнить произвольный код на веб-сервере. Palo Alto Unit 42 оценивает их в 9,2 балла по CVSS 4.0 и уже фиксирует наличие работающих proof-of-concept. Как минимум одно европейское правительство на всякий случай сняло свой сайт с публикации. Если у вас где-то крутится PHP — а он почти наверняка где-то крутится, — это тот случай, когда «разберёмся на следующей неделе» может стоить очень дорого.

Что именно сломалось в PHP

Обе уязвимости связаны с одним и тем же механизмом — обработкой фатальных ошибок через longjmp(). В C longjmp() — это грубый, но быстрый способ аварийно выпрыгнуть из глубоко вложенного вызова обратно в заранее отмеченную точку, минуя обычное раскручивание стека. PHP использует его, когда случается что-то катастрофическое: например, исчерпана память. Проблема в том, что при таком «прыжке» не выполняется корректная очистка и инициализация внутренних структур запроса — код оказывается в состоянии, которое он сам не ожидает.

CVE-2026-109618 описывает ситуацию, когда обработка ошибки out-of-memory (OOM) прерывает PHP в момент, когда внутренние данные запроса инициализированы лишь частично. Последующая очистка запроса (request cleanup) принимает невалидные данные за валидные. CVE-2026-109619 — это уже про «запаздывающее» состояние: внутренние структуры, принадлежащие запросу, переживают освобождение своей памяти. Следующий запрос, обработанный тем же рабочим процессом (worker), может обратиться к этому устаревшему состоянию раньше, чем нормальная инициализация его перезапишет.

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

CVE	Суть	CVSS 4.0
CVE-2026-109618	OOM прерывает запрос; cleanup принимает частично инициализированные данные за валидные	9,2
CVE-2026-109619	Состояние запроса переживает освобождение памяти и используется следующим запросом	9,2

Масштаб: 22,6 миллиона точек входа

PHP — это не просто «язык для сайтов». Он встроен в огромное количество CMS, фреймворков, панелей управления и — что особенно коварно — в прошивки сетевых устройств, принтеров, NAS и бытовой техники, где о его существовании никто не помнит. Именно поэтому телеметрия Palo Alto Cortex Xpanse выявила более 22,6 миллиона доступных из интернета экземпляров, потенциально уязвимых к этим двум CVE. Это не значит, что все они будут взломаны, но это значит, что поверхность атаки колоссальна.

Внимание: NCSC прямо предупреждает — не ограничивайте инвентаризацию только устаревшими версиями PHP. Уязвимыми могут оказаться любые версии, а значит, искать нужно все установки PHP в инфраструктуре, а не только те, что помечены как «давно не обновлялись».

Именно здесь кроется самая частая ошибка. Организация смотрит в свой реестр активов, видит актуальную версию PHP на основных серверах, ставит галочку «у нас всё обновлено» — и упускает из виду, что PHP quietly живёт в веб-интерфейсе VPN-концентратора, в админке системы резервного копирования или в каком-нибудь legacy-приложении, которое «работает и трогать нельзя». Голландский NCSC-NL опубликовал перечень программных продуктов с зависимостью от PHP, потенциально затронутых уязвимостями, — это хорошая отправная точка для сверки.

Как атака выглядит на практике

С точки зрения пентестера, цепочка здесь выглядит неприятно элегантной. Сначала — разведка: определить, что перед нами PHP-приложение, и, если повезёт, его версию. Затем — серия запросов, нацеленных на исчерпание памяти воркера в контролируемый момент. При удачном попадании срабатывает longjmp(), и внутреннее состояние запроса остаётся «грязным». Дальше — либо немедленное использование повреждения памяти в рамках того же запроса (CVE-2026-109618), либо «подсев» следующего запроса на освобождённую, но ещё не перезаписанную память (CVE-2026-109619).

Второй сценарий особенно коварен для защитников: атакующий может подготовить почву одним запросом и «выстрелить» другим, что усложняет корреляцию событий в логах. А поскольку PHP-приложения обслуживаются пулами воркеров, попадание в нужный процесс — вопрос перебора, а не удачи. Unit 42 подтверждает наличие PoC, а значит, порог входа для эксплуатации снижается с каждым днём.

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

Что делать: приоритеты и порядок

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

Инвентаризация. Найдите все системы с PHP, в первую очередь доступные из интернета. Не ограничивайтесь «старыми» версиями — уязвимы могут быть любые.
Мониторинг обновлений сторонних вендоров. Следите за апдейтами для устройств и сервисов, которые включают PHP как компонент, — там патч приходит не от PHP, а от производителя железа или софта.
Обновление до актуальной версии PHP. Установите последнюю исправленную версию и продолжайте отслеживать новые релизы.
Дополнительное усиление. Примените рекомендации по hardening, опубликованные командой PHP.
Временные меры. Если обновление невозможно, используйте временные митигации от PHP. Если и это нереально или займёт слишком много времени — рассмотрите вывод системы из эксплуатации до полного устранения.
Проверка на компрометацию. Если систему нельзя обновить или отключить немедленно, проверьте её на признаки взлома и бэкдоры до патчинга.

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

# Быстрая проверка версии PHP на хосте
php -v

# Поиск установок PHP в файловой системе (Linux)
find / -name 'php' -type f -perm -u+x 2>/dev/null

# Проверка пакетов, зависящих от PHP (Debian/Ubuntu)
dpkg -l | grep -i php

Для организаций, которые не уверены в собственных силах провести проверку на компрометацию, NCSC рекомендует обращаться к аккредитованным провайдерам реагирования на инциденты. Это разумно: отличить легитимный веб-шелл от штатного кода в чужом legacy-приложении без опыта непросто.

Почему это важнее, чем кажется

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

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

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

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