Урок уязвимости PHP: за открытый код отвечает выбравший его

20 октября 2026 года разработчики PHP опубликовали информацию об уязвимости и выпустили экстренные исправления. В России ситуация вызвала дополнительные меры реагирования: согласно сообщениям профильных СМИ, НКЦКИ при ФСБ направил рекомендации операторам критической информационной инфраструктуры. Организациям предписали в первую очередь обновить PHP, а если это невозможно сделать оперативно, то временно ограничить внешний доступ к уязвимым серверам, вплоть до их отключения. О подозрительных инцидентах необходимо сообщать в ГосСОПКА.

Хостинг-провайдеры также начали предупреждать клиентов и вводить временные ограничения, призванные уменьшить риск эксплуатации уязвимости.

Однако здесь обнаружилась проблема, которая выходит за рамки одной конкретной уязвимости: выпущенные исправления затронули версии PHP 8.2 и выше. Владельцам систем на более старых версиях приходится искать другой путь решения проблемы и не всегда он очевиден.

Официальные экстренные исправления вышли оперативно, но коснулись только поддерживаемых веток PHP (версии 8.2 и выше). Версии 8.1 и все более ранние релизы официально сняты с поддержки, и глобальная команда разработчиков PHP больше не выпускает для них обновления безопасности.

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

Принципиально важно разделять несколько уровней ответственности.

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

Но наличие каждого из этих участников само по себе не гарантирует, что кто-то возьмёт на себя сопровождение всей цепочки, особенно если организация использует устаревшую версию PHP.

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

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

Сама по себе открытая лицензия не делает программное обеспечение ненадёжным. Многие открытые технологии широко применяются в корпоративных и государственных системах и могут безопасно эксплуатироваться при наличии грамотного управления обновлениями и рисками.

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

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

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

В частности, при выборе технологической платформы стоит выяснять:

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