Уязвимость PHP на объектах КИИ: что требует НКЦКИ от бизнеса в 2026 году

НКЦКИ потребовала закрыть уязвимость PHP на объектах КИИ

22 октября 2026 года Национальный координационный центр по компьютерным инцидентам (НКЦКИ), работающий при ФСБ России, выпустил официальное требование: немедленно устранить критическую уязвимость PHP на объектах критической информационной инфраструктуры. Речь о паре уязвимостей — CVE-2026-109618 и CVE-2026-109619, получивших общее имя php2shell: вместе они позволяют захватить сервер без единого логина и пароля.

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

Чем опасны CVE-2026-109618 и CVE-2026-109619

Обе уязвимости получили критическую оценку по шкале CVSS — один из самых высоких уровней опасности, которые присваивают уязвимостям. CVE-2026-109618 связана с повреждением памяти при обработке нехватки памяти (OOM), а CVE-2026-109619 — use-after-free ошибка, возникающая из-за того, что часть состояния интерпретатора сохраняется между запросами. Проблема сидит в самом ядре PHP, поэтому обновления на уровне CMS или фреймворка её не закрывают — нужен патч интерпретатора.

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

Что означает критическая оценка CVSS и почему это критический уровень

CVSS (Common Vulnerability Scoring System) — стандартная шкала от 0 до 10, по которой оценивают серьёзность уязвимостей: 0,1–3,9 — низкий уровень, 4,0–6,9 — средний, 7,0–8,9 — высокий, 9,0–10,0 — критический. CVE-2026-109618 и CVE-2026-109619 классифицированы как критические уязвимости, находящиеся у верхней границы этого диапазона — случаи такого уровня критичности относительно редки.

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

Для сравнения: уязвимости такого уровня критичности в самом ядре PHP, а не в сторонней библиотеке, плагине или теме, встречаются нечасто. Большинство уязвимостей, которые обнаруживают регулярно, затрагивают конкретные CMS-плагины или расширения и устраняются обновлением одного компонента. php2shell устроен иначе: проблема сидит в коде, который обрабатывает любой PHP-скрипт, независимо от того, какое приложение на нём написано.

Чем уязвимость интерпретатора PHP отличается от уязвимости в CMS или плагине

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

CVE-2026-109618 и CVE-2026-109619 — это ошибки в самом интерпретаторе: в коде, который выполняется для любого PHP-скрипта вообще, прежде чем до логики конкретного сайта или приложения дойдёт хоть одна строка. Поэтому обновление CMS, плагина или фреймворка не закрывает уязвимость — даже полностью актуальная версия WordPress или 1С-Битрикс на уязвимой версии PHP остаётся под угрозой.

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

Какие CMS, фреймворки и платформы оказались в зоне риска

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

• сайты на WordPress — самой распространённой CMS в мире, включая корпоративные блоги и порталы самообслуживания;
• проекты на 1С-Битрикс — одной из основных CMS для корпоративных сайтов и интернет-магазинов в России и СНГ;
• сайты на Joomla и Drupal;
• самописные корпоративные веб-приложения и личные кабинеты на PHP без использования готовой CMS;
• внутренние панели администрирования и микросервисы на PHP-фреймворках (Laravel, Symfony, Yii и другие) — уязвимость в ядре языка затрагивает их так же, как и сайты на готовых CMS.

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

Кого касается требование НКЦКИ и в какие сроки

Формально требование НКЦКИ адресовано субъектам критической информационной инфраструктуры по 187-ФЗ — то есть широкому кругу организаций, которые обязаны следовать предписаниям регулятора при ФСБ. В список попадают:

• государственные органы;
• финансовые организации;
• энергетические компании;
• транспортные операторы;
• медицинские учреждения;
• операторы связи.

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

Формально обязанности по 187-ФЗ распространяются на субъектов КИИ — организации, которые владеют, арендуют или обслуживают значимые объекты критической информационной инфраструктуры. Такие организации обязаны категорировать свои объекты (категории значимости от 1 до 3, где 1 — самая высокая), применять меры защиты по требованиям ФСТЭК и ФСБ и сообщать об инцидентах в ГосСОПКА. Именно в силу этих обязательств предписания НКЦКИ по уязвимостям такого уровня адресуются субъектам КИИ напрямую, а не носят рекомендательный характер.

Что сделать бизнесу прямо сейчас

Чтобы закрыть уязвимость PHP на своих объектах КИИ и снизить риск ответственности за нарушение предписания регулятора, НКЦКИ рекомендует следующую последовательность действий:

1. Установить обновления PHP — 8.2.35, 8.3.36, 8.4.27 или 8.5.12 в зависимости от используемой ветки.
2. Если быстрое обновление невозможно — ограничить внешний доступ к серверу, вплоть до его временного отключения.
3. Проверить серверы антивирусными средствами.
4. Изучить журналы событий на предмет следов взлома, которые могли остаться до публикации патча.
5. Сообщить о подозрительных инцидентах в дежурный центр ГосСОПКА.

Обновление на Apache с mod_php

Самая рискованная конфигурация: при использовании mod_php интерпретатор работает как модуль веб-сервера, и уязвимый код может сработать ещё до того, как запрос передан в код приложения. Порядок действий: определить текущую версию модуля и интерпретатора (команды apachectl -M и php -v на сервере), обновить пакет PHP через менеджер пакетов дистрибутива до версии, закрывающей уязвимость, и перезапустить Apache (systemctl restart apache2 либо httpd), чтобы модуль подхватил новую версию.

Обновление на связке nginx + PHP-FPM

Самая распространённая конфигурация на корпоративных и высоконагруженных проектах. Nginx сам по себе не выполняет PHP-код — он передаёт запросы процессу PHP-FPM, поэтому обновлять нужно именно пакет PHP-FPM. После установки новой версии процесс FPM нужно перезапустить (systemctl restart php-fpm, либо под именем конкретной версии, например php8.3-fpm), а не просто перечитать конфигурацию nginx — иначе воркеры останутся работать на старой, уязвимой версии интерпретатора.

Обновление при использовании PHP-CGI, FrankenPHP и LiteSpeed

Для конфигураций с php-cgi или FastCGI-прокси принцип тот же: обновляется сам интерпретатор, после чего перезапускается соответствующий процесс или пул воркеров. Для FrankenPHP и LiteSpeed — серверов, которые всё чаще используют для PHP-проектов из-за производительности, — нужно отдельно проверить, какая версия PHP встроена в сам дистрибутив сервера: обновление системного пакета PHP в этом случае может не затронуть версию, скомпилированную внутрь самого веб-сервера, и потребуется обновление уже самого FrankenPHP или LiteSpeed до версии со свежим PHP.

Если сайт работает на выделенном хостинге или в облаке

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

Как проверить версию PHP без прямого доступа к серверу

Если доступа к консоли сервера нет, но есть доступ к самому сайту, версию PHP иногда можно увидеть в заголовке ответа веб-сервера X-Powered-By, если он не отключён администратором из соображений безопасности. Но наиболее надёжный способ — всё же запросить версию напрямую у ответственного за сервер: заголовки могут быть скрыты, а информация в админ-панели CMS не всегда отражает фактическую версию интерпретатора.

Хронология: от первых атак до предписания НКЦКИ

Если собрать воедино факты, которые уже известны об этой истории, картина складывается следующим образом:

• по данным зарубежных исследователей, первые попытки эксплуатации фиксировались примерно за четыре дня до публичного раскрытия информации о CVE-2026-109618 и CVE-2026-109619 — то есть до того, как у администраторов появилась возможность узнать о проблеме и установить патч;
• 21 октября 2026 года вышли исправленные версии PHP — 8.2.35, 8.3.36, 8.4.27 и 8.5.12, закрывающие обе уязвимости;
• 22 октября 2026 года НКЦКИ выпустил официальное требование к субъектам КИИ немедленно устранить уязвимость.

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

Почему уязвимость PHP — это ещё и риск для привилегированного доступа

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

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

Минимальный план проверки после такого инцидента включает несколько шагов:

• проверить журналы входа администраторов и привилегированных пользователей за период, предшествующий выходу патча;
• убедиться, что вход в критичные системы — серверы, панели администрирования, VPN — защищён многофакторной аутентификацией, а не только паролем;
• убедиться, что действия администраторов серверов с уязвимой версией PHP записываются и доступны для разбора — это заметно ускоряет расследование, если следы компрометации всё же найдутся;
• при обнаружении подозрительной активности не ограничиваться обновлением PHP, а провести полноценное расследование инцидента и сообщить о нём в ГосСОПКА, как и рекомендует НКЦКИ.

Частые вопросы

Что такое php2shell?

Это общее название для двух критических уязвимостей PHP — CVE-2026-109618 и CVE-2026-109619, которые позволяют выполнить произвольный код на сервере без авторизации, с правами процесса, обрабатывающего веб-запросы.

Какие версии PHP нужно установить, чтобы закрыть уязвимость?

В зависимости от используемой ветки — 8.2.35, 8.3.36, 8.4.27 или 8.5.12. Эти версии вышли 21 октября 2026 года и содержат исправления обеих уязвимостей.

Что делать, если обновить PHP сразу не получается?

НКЦКИ рекомендует ограничить внешний доступ к серверу вплоть до временного отключения — до момента, когда обновление будет установлено.

Кому адресовано требование НКЦКИ по уязвимости PHP на объектах КИИ?

Субъектам критической информационной инфраструктуры по 187-ФЗ: государственным органам, финансовым организациям, энергетическим и транспортным компаниям, медицинским учреждениям и операторам связи.

Почему уязвимость опасна даже после установки патча?

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

Как проверить версию PHP на своём сервере?

Проще всего выполнить команду php -v в консоли сервера или посмотреть версию, указанную в конфигурации пула PHP-FPM. Если прямого доступа к серверу нет, информацию нужно запросить у ответственного за инфраструктуру — хостинг-провайдера, подрядчика или внутреннего ИТ-отдела.

Достаточно ли обновить CMS или плагины, чтобы закрыть уязвимость?

Нет. Уязвимость находится в самом интерпретаторе PHP, а не в коде CMS или плагина, поэтому обновление приложения её не устраняет. Нужно обновить непосредственно версию PHP на сервере и перезапустить соответствующий процесс — Apache с mod_php, PHP-FPM или другой используемый обработчик.

Что делать, если сайт нельзя отключить даже временно?

Если сервис критичен и его отключение недопустимо, а обновление PHP требует предварительного тестирования, НКЦКИ рекомендует как минимум ограничить внешний доступ — например, временно оставить доступ только через VPN или список разрешённых IP-адресов для внутренних пользователей, пока не будет установлен патч. Это не заменяет обновление, но снижает окно для атаки через публичный интернет.

Нужно ли менять пароли и ключи после обновления PHP?

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

Итог: патч — это только первый шаг

Требование НКЦКИ закрыть уязвимость PHP на объектах КИИ — хороший повод не только обновить интерпретатор, но и посмотреть шире: кто и как получает привилегированный доступ к серверам компании, фиксируются ли действия администраторов и есть ли вторая проверка личности при входе в критичные системы. Такие инциденты редко ограничиваются одной уязвимостью — обычно за внешним прорывом следует попытка закрепиться через скомпрометированные учётные записи.

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

В частности, такие решения, как Контур.Эгида, объединяют многофакторную аутентификацию для входа в критичные системы, контроль действий привилегированных пользователей и мониторинг инцидентов в одном контуре защиты — без необходимости перестраивать всю ИТ-инфраструктуру ради отдельных точечных мер.

📢 Следим за изменениями в законах и сервисах для бизнеса каждый день. Канал «Контур-Центр» в Telegram — чтобы новости приходили к вам сами.