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

PHP2Shell, или угроза 70% веб-приложений

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 и двенадцать лет уязвимых релизов

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

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

Откуда столько уязвимостей и при чем здесь ИИ

Обе уязвимости 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

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