Критические уязвимости PHP и GitLab: как Apsafe помогает защитить приложения

В статье рассказываем, как устроены обе уязвимости, почему обновление не всегда закрывает проблему и какие меры защиты актуальны сейчас.

21 октября команда PHP выпустила экстренные обновления, закрывающие две уязвимости под общим названием PHP2Shell. Им присвоены идентификаторы CVE-2026-109618 и CVE-2026-109619, каждая получила 9,2 балла из 10 по шкале CVSS 4.0. Первая ошибка проявляется, когда запрос упирается в лимит памяти в неудачный момент и внутренние структуры остаются инициализированными лишь частично. Вторая относится к классу use-after-free. После фатальной ошибки процесс сохраняет ссылку на уже освобожденную память, и следующий запрос, попавший в тот же worker, обращается к ней раньше, чем процесс очистит его для нового запроса. В обоих случаях атакующему достаточно отправить специально подготовленный HTTP-запрос, чтобы выполнить произвольный код, не имея учетной записи.

Масштаб проблемы определяется тем, насколько распространен PHP. На нем работает около 70% сайтов, серверный язык которых известен. Уязвимы все способы обслуживания запросов, включая PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Самым опасным вариантом команда PHP называет
mod_php, где вредоносный запрос срабатывает еще до запуска кода сайта. Затронуты версии вплоть до 5.4, и уязвимым оказывается даже приложение из одной строки. Обновить WordPress, Drupal или плагины недостаточно, потому что ошибка находится в самом интерпретаторе на сервере. Исправления вошли в PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35, а для неподдерживаемых веток 7.4, 8.0 и 8.1 команда выпустила исправления для самостоятельной сборки.

В тот же день GitLab закрыл уязвимость CVE-2026-110264 с максимальной оценкой 10.0. Целочисленное переполнение при компиляции специально составленного регулярного выражения позволяет неавторизованному пользователю выполнить код на сервере. Ошибка находится в Onigmo, встроенном движке регулярных выражений Ruby, который GitLab поставляет в своих пакетах. Этот движок входит в GitLab с версии 7.0, поэтому уязвимы все релизы с 2014 года.

За месяц исследователь сообщил о четырех уязвимостях выполнения кода в одном и том же компоненте. Исправление от 12 октября закрывало предыдущую ошибку только для версий 19.2 и новее. Администраторы, которые добросовестно обновились девять дней назад, снова оказались в зоне риска. Компания не раскрыла, при каких условиях атакующий может добраться до уязвимого кода, и не предложила временного обходного решения. Сообщений о реальной эксплуатации пока не сообщалось , однако сервер с исходным кодом, секретами CI/CD и доступами к продакшн-окружениям остается одной из самых ценных целей в любой инфраструктуре.

Обе уязвимости PHP найдены с помощью искусственного интеллекта. Одну обнаружила команда Calif в ходе аудита PHP по программе OpenAI «Patch the Planet», а компания Wiz независимо нашла и передала разработчикам обе ошибки. В OpenAI заявили, что их модели нашли эти уязвимости раньше злоумышленников. Это действительно хороший результат, ведь ошибки в управлении памятью интерпретатора годами оставались незамеченными при ручном аудите.

У этого прогресса есть обратная сторона. Модели, которые помогают исследователям находить дефекты в обращении к памяти, также хорошо помогают разбирать опубликованные исправления и собирать по ним эксплойты. В случае PHP2Shell идентификаторы и часть технических сведений попали в открытый доступ за день до планового раскрытия. Уже 22 октября исследователи VulnCheck показали эксплойт, который обходит защиту ASLR и без доработок работает на версиях PHP от 8.4.10 до 8.4.26. Специалисты watchTowr сообщали о попытках эксплуатации в первые же дни, хотя подтвержденных случаев взлома на момент раскрытия не было.

Злоумышленники тоже автоматизируют свою работу. На прошлой неделе исследователи описали автономного ИИ-агента, которого атакующие использовали для захвата серверов. Агент сам сканировал интернет, проверял найденные системы на уязвимости, похищал учетные данные и устанавливал майнеры, причем мог выполнить до ста тысяч шагов без участия человека. Когда поиск целей и подбор эксплойтов берет на себя машина, путь от публикации CVE до массовых атак сокращается до часов.

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

Затем обновление нужно протестировать, согласовать окно обслуживания и пережить простой. Например, версии GitLab 19.3.6 и 19.4.3 включают миграции базы данных, и на одноузловой установке это означает остановку сервиса. Компании, которые используют устаревшие ветки PHP, вынуждены либо собирать исправления самостоятельно, либо ждать пакетов от поставщика дистрибутива. В крупной инфраструктуре этот процесс растягивается на дни и недели, а уязвимость все это время остается открытой. Команда PHP предложила изменить лимиты памяти и отключить отслеживание загрузки в сессиях, но прямо предупредила, что такие настройки перекрывают лишь известные пути атаки и не заменяют патч.

Основной риск приходится именно на промежуток между раскрытием уязвимости и установкой исправления. Закрыть его помогает контроль поведения приложений во время работы, или runtime-безопасность. Такой подход не требует знать конкретную CVE. Он исходит из того, что легитимное приложение ведет себя предсказуемо, а успешная атака неизбежно меняет это поведение. Рабочий процесс веб-сервера обслуживает запросы и не должен порождать shell. Если в контейнере вдруг появляется интерпретатор, за которым следуют разведывательные команды и обращения к внешним адресам, значит, атака уже идет, и неважно, через какую уязвимость она началась.

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

Встроенные правила Luntry основаны на сигнатурах и срабатывают на типичные действия во время и после взлома. Luntry замечает, когда процесс веб-сервера запускает shell, в командах появляются характерные для reverse shell конструкции вроде /dev/tcp и mkfifo, кто-то выполняет whoami и id или читает переменные окружения, в которых часто хранятся секреты. Библиотека правил покрывает матрицу MITRE ATT&CK для контейнеров, и клиент может добавлять собственные детекты.

Когда правило срабатывает, Luntry может не только предупредить команду безопасности, но и отреагировать автоматически. ПО сохраняет дамп файловой системы и оперативной памяти для расследования и останавливает скомпрометированный контейнер. Разработчики Luntry проверили этот сценарий на стенде в Kubernetes с публичным эксплойтом PHP2Shell для официального образа php:8.4.26-apache. Контейнер был остановлен прямо в ходе атаки, следующий запрос эксплойта получил отказ в соединении, и цепочка атаки оборвалась (подробнее в статье Luntry).

Кроме того, Luntry заранее сужает возможности атакующего. Политики предотвращения разрешают запуск только тех процессов, которые действительно нужны приложению. Автоматически сгенерированные сетевые политики Kubernetes не дают скомпрометированному контейнеру связываться с посторонними адресами и соседними сервисами.

Мы рекомендуем в первую очередь установить исправления PHP и GitLab, начав с систем, доступных из интернета. Параллельно стоит провести инвентаризацию и выяснить, в каких работающих контейнерах остались уязвимые версии, включая сторонние продукты со встроенным PHP. На время обновления уязвимые нагрузки нужно взять под runtime-контроль с правилами на запуск оболочек и ограничением сетевых соединений. После этого имеет смысл закрепить результат проверками в CI, чтобы старые уязвимости не вернулись в кластер с очередным деплоем.

Apsafe — платформа для анализа защищенности приложений и внедрения практик DevSecOps от Центра кибербезопасности УЦСБ. Она объединяет инструменты проверки безопасности кода, зависимостей, приложений и контейнерной инфраструктуры, помогая выявлять уязвимости на разных этапах жизненного цикла ПО.

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

Apsafe Container Security на базе Luntry дополняет эти возможности защитой работающей контейнерной инфраструктуры: контролирует поведение приложений во время выполнения, выявляет подозрительные действия и помогает предотвращать развитие атак. Доступно облачное и локальное развертывание, а инструменты платформы можно встроить в существующие процессы разработки.