← Все статьи
Новости

Критические уязвимости в PHP: экстренные меры для ИТ-инфраструктуры российского ритейла

26.10.2026 · 6 мин чтения

По данным [iXBT News](https://www.ixbt.com/news/2026/10/22/fsb-vypustila-srocnoe-preduprezdenie-iz-za-php-esli-sait-nevozmozno-operativno-obnovit-to-dostup-k-nemu-sleduet-ogranicit.html), Национальный координационный центр по компьютерным инцидентам (НКЦКИ) при ФСБ России выпустил предписание для объектов критической информационной инфраструктуры (КИИ) в связи с обнаружением двух критических уязвимостей в языке PHP. Документ от 22 октября обязывает организации, включая финансовые и государственные, в экстренном порядке обновить PHP или, если это невозможно, ограничить доступ к уязвимым веб-ресурсам. Уязвимости, одна из которых была найдена с помощью ИИ, имеют оценку 9,2 из 10 по шкале CVSS и позволяют осуществить удаленное выполнение кода и кражу данных.

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

Национальный координационный центр по компьютерным инцидентам (НКЦКИ) разослал экстренное уведомление организациям, относящимся к критической информационной инфраструктуре. Причиной послужили две уязвимости в интерпретаторе PHP, для которых 21 октября были выпущены экстренные патчи. Эти бреши позволяют злоумышленнику удаленно выполнить произвольный код на сервере, получить полный контроль над системой и извлечь из оперативной памяти конфиденциальную информацию, включая пароли администраторов, сессионные токены и криптографические ключи.

Особую тревогу вызывает происхождение одной из уязвимостей — она была обнаружена с использованием искусственного интеллекта, что демонстрирует новый уровень сложности и автоматизации в поиске векторов атак. Масштаб угрозы колоссален: по информации аналитических систем, PHP используется на подавляющем большинстве сайтов с русскоязычным контентом. Важно понимать, что простое обновление CMS (WordPress, Joomla, 1С-Битрикс) не решает проблему, так как уязвимость находится на уровне серверного ПО, а не прикладного. Инструкция НКЦКИ предписывает следующий алгоритм действий:

Почему это важно

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

1. Публичные веб-сайты и e-commerce платформы. Интернет-магазины, промо-страницы, системы лояльности и личные кабинеты клиентов в подавляющем большинстве случаев работают на стеке LAMP/LEMP (Linux, Nginx/Apache, MySQL, PHP). Успешная атака означает не только дефейс сайта, но и кражу базы данных клиентов (ФИО, телефоны, адреса, история заказов), что является прямым нарушением 152-ФЗ. Компрометация административного доступа позволяет внедрить платежный скиммер (Magecart-атака) для перехвата данных банковских карт.

2. Внутренние порталы и B2B-системы. Экстранет-сети для поставщиков, системы управления заказами (OMS), внутренние CRM и складские системы (WMS) часто имеют веб-интерфейс на PHP. Доступ к ним дает злоумышленникам карту всей логистической и закупочной цепочки компании.

3. Интеграционные шины и API. Многие middleware-решения, которые связывают кассовое ПО, мобильное приложение для курьеров, ERP-систему (например, 1С) и сайт, используют PHP для обработки входящих запросов. Уязвимость здесь может нарушить всю бизнес-логику: от синхронизации остатков до передачи фискальных данных.

4. Смежные риски. Для компаний, использующих или планирующих переход на отечественные мобильные ОС (Аврора) для своих сотрудников (мерчандайзеров, аудиторов), компрометация корпоративного портала означает компрометацию точки входа для управления этими устройствами. Если злоумышленник получит доступ к серверу, где развернут MDM-компонент или API для /docs/aurora, он сможет отдать команду на сброс или кражу данных с корпоративных планшетов и смартфонов.

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

Что делать

ИТ-департаменту розничной сети необходимо действовать по четкому плану, разделяя экстренные и системные меры.

Экстренные меры (в течение 24 часов)

1. Аудит и инвентаризация. Проведите экстренный поиск всех публичных и внутренних серверов, использующих PHP. Команды для быстрой проверки на уровне ОС могут выглядеть так:

    # Поиск процессов php-fpm или mod_php
    ps aux | grep php
    # Проверка установленной версии
    php -v

2. Приоритезация. Составьте список активов. На первом месте — серверы, обрабатывающие платежи и ПДн клиентов. На втором — внутренние системы. На третьем — вспомогательные ресурсы.

3. Обновление. Немедленно обновите PHP до версии, в которой устранены уязвимости (уточняйте номер версии в [официальном репозитории PHP](https://www.php.net/archive/2026)). Если используется хостинг, откройте срочный тикет провайдеру. Если инфраструктура на виртуальных машинах — запустите процедуру обновления через конфигурационный менеджер (Ansible, Chef).

4. WAF и изоляция. Если обновление невозможно по причинам совместимости (например, устаревшая версия 1С-Битрикс), немедленно активируйте строгие правила на сетевом экране (Web Application Firewall) для блокировки известных сигнатур эксплуатации уязвимостей. В крайнем случае — настройте файрвол (iptables/nftables) так, чтобы доступ к портам 80/443 на уязвимом сервере имели только IP-адреса вашей корпоративной сети и офиса разработки.

5. Проверка целостности. После обновления запустите антивирусную проверку (например, ClamAV или решения от российских вендоров) и развернутые агенты EDR. Внимательно изучите логи веб-сервера (Nginx/Apache) за последние 72 часа на предмет запросов с подозрительными строками в URL или User-Agent.

Системные меры (на ближайшие 2 недели)

1. End-of-Life (EOL) политика. Составьте полный реестр используемого ПО. Любые серверы, работающие на неподдерживаемых версиях PHP (ниже PHP 8.1), должны быть внесены в план миграции. Использование EOL-софта в ритейле недопустимо.

2. Сегментация сети. Убедитесь, что веб-серверы находятся в DMZ (демилитаризованной зоне) и не имеют прямого доступа к базам данных с ПДн или серверам ERP-систем. Доступ между сегментами должен быть разрешен строго по IP и портам.

3. Централизованное управление. Внедрите или актуализируйте политики управления конфигурациями. Все изменения версий ПО на серверах должны проходить через единую систему, а не настраиваться вручную. Это исключает появление "забытых" уязвимых серверов.

4. Синхронизация с MDM. Проверьте политики безопасности на ваших мобильных устройствах в [Komendant MDM](/docs/policies). Убедитесь, что доступ к корпоративным ресурсам с мобильных устройств требует прохождения проверок на актуальность ОС и отсутствие джейлбрейка/root. Настройте интеграцию через /docs/scim для быстрой блокировки учетных записей сотрудников, чьи сессии могли быть скомпрометированы через украденные с сервера токены.

5. Регламентация отчетности. Проведите инструктаж для службы мониторинга и первой линии поддержки. Четко пропишите алгоритм: при обнаружении аномалий на веб-серверах (резкий рост трафика, ошибки 5xx) немедленно эскалировать инцидент на ответственного за ИБ и готовить данные для отчета в ГосСОПКУ.

Источник: https://www.ixbt.com/news/2026/10/22/fsb-vypustila-srocnoe-preduprezdenie-iz-za-php-esli-sait-nevozmozno-operativno-obnovit-to-dostup-k-nemu-sleduet-ogranicit.html

← Вернуться ко всем статьям