21 октября 2026 года PHP Security Team выпускает экстренное обновление безопасности, закрывающее две критические уязвимости с оценкой CVSS 9.2 из 10. Под потенциальной угрозой оказываются тысячи корпоративных сайтов, интернет-магазинов и веб-приложений, построенных на PHP. Разбираемся, что происходит, кому стоит беспокоиться и почему для бизнеса проблема может оказаться гораздо серьёзнее обычного обновления CMS.
Что произошло?
20 октября команда разработчиков PHP опубликовала предупреждение о двух критических уязвимостях, получивших идентификаторы CVE-2026-109618 и CVE-2026-109619.
Выпуск исправлений запланирован на 21 октября, 14:00 UTC (16:00 по центральноевропейскому летнему времени).
Обе уязвимости получили оценку 9.2 по шкале CVSS 4.0, что соответствует критическому уровню опасности.
По информации CERT-EU, речь может идти о возможности удалённого выполнения произвольного кода (Remote Code Execution, RCE) без предварительной аутентификации.
Это один из наиболее опасных классов уязвимостей: при определённых условиях злоумышленник может получить возможность выполнять код на сервере, обрабатывающем запросы пользователей.
Важно: на момент подготовки статьи технические детали уязвимостей и окончательный список затронутых версий PHP ещё не опубликованы. Поэтому сценарии эксплуатации рассматриваются как потенциальные, а не подтверждённые для каждой PHP-инсталляции.
Причём здесь WordPress и Drupal?
PHP остаётся основой значительной части веб-инфраструктуры. На нём работают популярные системы управления контентом и коммерческие платформы:
- WordPress — корпоративные сайты, блоги, маркетинговые порталы.
- Drupal — государственные порталы, корпоративные системы и информационные ресурсы.
- Magento / Adobe Commerce — интернет-магазины и платформы электронной коммерции.
- Joomla — сайты организаций и компаний.
- Laravel и Symfony — многочисленные корпоративные приложения, API и внутренние сервисы.
Особенность текущей ситуации заключается в том, что предупреждение касается самого PHP, а не отдельного плагина или CMS.
Иными словами, даже полностью обновлённый WordPress потенциально может оказаться уязвимым, если работает на затронутой версии PHP.
Наличие конкретной CMS само по себе ещё не означает, что сайт можно атаковать. Это будет зависеть от механизма уязвимости, конфигурации сервера и доступности уязвимого кода.
Почему для корпораций ситуация особенно опасна?
В небольших проектах обновление PHP иногда ограничивается несколькими действиями в панели хостинга. В корпоративной инфраструктуре всё значительно сложнее.
1. Устаревшие приложения
Во многих компаниях продолжают работать сайты и приложения, созданные пять, десять и более лет назад.
Такие системы могут использовать старые версии PHP, несовместимые с современными релизами.
Обновление runtime в подобных проектах способно привести к ошибкам в приложении, несовместимости библиотек и отказу критичных функций.
В результате компания оказывается перед неприятным выбором: продолжать эксплуатацию потенциально уязвимой системы или срочно проводить модернизацию приложения.
Причём для версий PHP, вышедших из официальной поддержки, исправление может вообще не появиться в upstream. В отдельных случаях проблему решают коммерческие программы расширенной поддержки или патчи поставщиков Linux-дистрибутивов.
2. Один сервер — десятки сайтов
Распространённая корпоративная практика — размещение нескольких сайтов на одной виртуальной машине или в общем окружении хостинга.
Если приложения работают без надлежащей изоляции, компрометация одного сайта может поставить под угрозу соседние ресурсы.
Масштаб последствий зависит от настроек системных пользователей, файловых разрешений, контейнеризации и сетевой сегментации.
3. Доступ к внутренней инфраструктуре
Современный корпоративный сайт редко существует изолированно.
Он может взаимодействовать с CRM, ERP, внутренними API, базами данных, объектными хранилищами и системами авторизации.
При успешной эксплуатации уязвимости злоумышленник потенциально получает доступ не только к сайту, но и к ресурсам, доступным процессу приложения.
Именно поэтому последствия RCE могут выходить далеко за пределы веб-сервера.
4. Длительные процедуры обновления
В крупных организациях обновления проходят через тестирование, согласование изменений, проверку совместимости и планирование релиза.
Обычно такой подход оправдан: он снижает риск нарушения работы бизнес-систем.
Однако при критических уязвимостях время начинает работать против компании.
После публикации исправления исследователи и злоумышленники могут анализировать изменения в исходном коде, чтобы определить механизм уязвимости.
Таким образом, между выпуском патча и его установкой возникает потенциально опасное окно.
Насколько реальна угроза массовых атак?
Уязвимости уровня RCE с высокой оценкой критичности закономерно привлекают внимание специалистов по безопасности и злоумышленников.
После публикации исправлений возможен быстрый анализ изменённого кода и создание автоматизированных средств эксплуатации.
Это особенно актуально для популярных платформ, доступных непосредственно из интернета.
Но важно не путать потенциальную опасность с уже состоявшейся атакой.
На момент написания статьи нет достаточных подтверждений массовой успешной эксплуатации этих двух уязвимостей. Поэтому прогнозировать конкретные масштабы инцидентов пока преждевременно.
Тем не менее организациям следует готовиться к сценарию, в котором время на установку обновления будет измеряться часами, а не неделями.
Что необходимо сделать прямо сейчас?
Для IT-департаментов и команд DevOps мы рекомендуем следующий план действий.
Шаг 1. Провести инвентаризацию
Необходимо определить все системы, использующие PHP, включая:
- Публичные корпоративные сайты.
- Интернет-магазины.
- Лендинги и маркетинговые страницы.
- Устаревшие приложения.
- Внутренние порталы и API.
- Контейнеры и виртуальные машины с PHP-FPM или Apache mod_php.
Особое внимание стоит уделить проектам, которые давно не обновлялись или не имеют ответственной команды сопровождения.
Шаг 2. Определить версии PHP
Необходимо установить, какие именно версии PHP используются в production.
При этом недостаточно проверить версию через командную строку. В некоторых инфраструктурах PHP CLI и PHP-FPM используют разные бинарные файлы и конфигурации.
Для контейнерных приложений следует проверить используемые base images и убедиться, что обновлённые образы действительно включают исправления.
Шаг 3. Подготовить экстренное обновление
После публикации исправленных версий необходимо сопоставить их с используемыми runtime и спланировать rollout.
Для современных инфраструктур с CI/CD процесс может включать:
- Обновление PHP или базового Docker-образа.
- Автоматическую сборку приложения.
- Smoke-тесты ключевых бизнес-функций.
- Развёртывание на staging или canary.
- Обновление production и проверку доступности.
Организациям без автоматизированных процессов стоит заранее определить ответственных и согласовать аварийную процедуру изменений.
Шаг 4. Ограничить потенциальный ущерб
Если обновление невозможно выполнить оперативно, следует рассмотреть временные меры:
- Ограничение публичного доступа к некритичным приложениям.
- Дополнительную сетевую изоляцию серверов.
- Минимизацию прав PHP-процессов.
- Ограничение доступа к базам данных и внутренним API.
- Проверку правил WAF и мониторинга безопасности.
- Усиленный контроль исходящих соединений.
Следует учитывать, что наличие CDN или WAF не гарантирует защиты от неизвестного механизма эксплуатации.
Шаг 5. Проверить готовность к восстановлению
Даже своевременное обновление не исключает возможность компрометации до установки патча.
Поэтому необходимо проверить резервные копии данных и конфигураций, доступность чистых образов, процедуры восстановления и изоляцию backup-хранилищ.
Особенно важно убедиться, что резервные копии нельзя удалить или изменить, используя учётные данные скомпрометированного приложения.
Более широкая проблема: зависимость бизнеса от устаревших технологий
История с PHP демонстрирует системную проблему корпоративной IT-инфраструктуры.
Многие компании годами эксплуатируют приложения, которые выполняют свои функции, но становятся всё сложнее в обслуживании.
Обновление операционной системы требует обновления библиотек. Обновление PHP — переработки приложения. Обновление CMS — проверки плагинов и интеграций.
В результате стоимость даже небольшого security update может оказаться непропорционально высокой.
При этом откладывание модернизации лишь увеличивает технический долг.
Может ли современная архитектура снизить риски?
Да, хотя полностью исключить уязвимости невозможно.
Мы в «Индевлабс» давно используем контейнеризацию, Kubernetes, Infrastructure as Code и автоматизированные CI/CD-процессы как основу для более управляемой инфраструктуры.
Такой подход позволяет стандартизировать окружения, быстрее разворачивать исправления, проверять обновления до production и ограничивать последствия компрометации отдельных компонентов.
Для контентных сайтов стоит также рассмотреть архитектуру с предварительной генерацией страниц — Static Site Generation (SSG).
В отличие от традиционной динамической CMS, статический сайт не требует выполнения PHP при каждом пользовательском запросе.
Контент можно хранить в отдельной Headless CMS, а пользователям предоставлять заранее подготовленные HTML-страницы через CDN.
Это не отменяет необходимости защищать саму CMS, административные интерфейсы и процессы сборки, но позволяет существенно сократить поверхность атаки публичной части сайта.
Разумеется, такой подход подходит не всем приложениям. Интернет-магазины, личные кабинеты и другие динамические сервисы требуют отдельного анализа архитектуры.
Выводы
Предстоящий security patch для PHP — серьёзное напоминание о том, что безопасность корпоративного сайта определяется не только актуальностью CMS и её плагинов.
Не менее важны используемый runtime, архитектура приложения, сетевая изоляция, права доступа и способность команды быстро внедрять обновления.
Главная задача бизнеса — не просто установить очередной патч, а создать инфраструктуру, в которой критическое обновление не превращается в многонедельный проект.
Для компаний с большим количеством WordPress, Drupal и других PHP-приложений нынешняя ситуация — хороший повод проверить, насколько быстро организация способна реагировать на подобные угрозы.
И если выясняется, что обновление одного компонента требует значительных усилий, возможно, пора задуматься не только о безопасности, но и о модернизации всей платформы.
Нужна помощь с аудитом или модернизацией инфраструктуры?
Indevlabs помогает компаниям проводить технический аудит, устранять инфраструктурные риски, внедрять контейнеризацию, CI/CD, резервное копирование и стратегии Disaster Recovery.
Мы помогаем сделать инфраструктуру более безопасной, управляемой и готовой к неожиданным ситуациям.
Источники
- PHP Security Team — Upcoming Critical PHP Security Release
- CERT-EU — Critical Vulnerabilities in PHP, Advisory 2026-018
Материал подготовлен 21 октября 2026 года до публикации технических деталей и исправленных версий PHP. Информация о затронутых версиях и способах эксплуатации требует уточнения после официального релиза.