Критическая уязвимость GitLab CVE-2026-97229 уже используется в атаках, подтвердило американское агентство CISA. Ошибка позволяет удалённо выполнить произвольный код на GitLab-сервере без аутентификации — достаточно специально подготовленного регулярного выражения в конфигурации CI/CD. Для команд, которые держат GitLab в собственной инфраструктуре, это не очередной пункт в еженедельном списке обновлений, а повод проверить версии прямо сейчас.
По данным BleepingComputer, проблему обнаружил исследователь под псевдонимом joaxcar в компоненте CI/CD Regular Expression Compiler. Он разбирает, компилирует и вычисляет регулярные выражения, используемые в конфигурационных файлах пайплайнов. Причина CVE-2026-97229 — целочисленное переполнение и недостаточная проверка выражений. В определённых условиях вредоносное регулярное выражение может привести к запуску кода на стороне GitLab.
GitLab выпустила исправления в версиях Community Edition и Enterprise Edition 19.4.2, 19.3.5 и 19.2.8. Компания также подготовила детектирующие правила для клиентов с self-managed-инсталляциями после того, как зафиксировала попытки эксплуатации. Важная деталь здесь не в самом факте выхода патча: теперь атаки подтверждены внешним регулятором, а значит, окно между публикацией исправления и массовым поиском уязвимых серверов, похоже, уже закрылось.
30 октября CISA внесло CVE-2026-97229 в каталог Known Exploited Vulnerabilities — перечень уязвимостей, которые реально применяются злоумышленниками. Федеральным ведомствам США предписано защитить затронутые системы до воскресенья в рамках Binding Operational Directive 26-04. Формально это требование относится только к американским госорганам, но его практический смысл универсален: если уязвимость попала в KEV, откладывать патч в надежде на спокойное окно обслуживания — рискованная стратегия.
Для российских компаний это особенно чувствительно там, где GitLab одновременно хранит исходный код, запускает сборки, содержит переменные окружения и обслуживает внутренние пакеты. Получив выполнение кода на сервере, атакующий потенциально оказывается в точке, из которой удобно двигаться к секретам CI/CD, токенам доступа, ключам деплоя и инфраструктуре. Конкретный масштаб последствий зависит от настроек инстанса и сегментации сети, но сам вектор опасен именно тем, что бьёт по центральному элементу инженерного контура.
В открытом интернете, по данным Shadowserver, доступно почти 2,8 тыс. экземпляров GitLab Community Edition. Сколько из них уже обновлено, неизвестно. Эта неопределённость — подарок для сканеров: после публикации номера CVE, версий с исправлением и подтверждения эксплуатации достаточно быстро появляются массовые проверки доступных хостов. Закрытый от интернета GitLab тоже не стоит автоматически считать безопасным: атака может прийти через скомпрометированную учётную запись, внутренний доступ или цепочку поставки.
Инцидент укладывается в неприятную серию проблем GitLab в 2026 году. В январе компания исправила CVE-2026-0723 — обход двухфакторной аутентификации для атакующего, знающего идентификатор целевой учётной записи. Ранее в октябре были закрыты ещё две уязвимости максимальной степени опасности: CVE-2026-110264 в компиляторе регулярных выражений с возможностью удалённого выполнения кода и CVE-2026-85706 в API коммитов, через которую можно было читать конфиденциальные данные, включая учётные данные и секреты. Уже на следующий день после сообщения о CVE-2026-85706 CISA добавило её в список активно эксплуатируемых уязвимостей.
За этим набором CVE легко потерять операционную картину. GitLab — не просто веб-интерфейс для репозиториев: в большинстве зрелых команд он связан с раннерами, облаками, реестрами образов, системами доставки и корпоративными каталогами. Поэтому владельцам платформы стоит не ограничиваться обновлением пакета. Нужны инвентаризация всех инстансов, проверка фактических версий, ревизия внешней доступности, анализ журналов на необычные изменения CI/CD-конфигураций и готовность отозвать токены, если есть признаки компрометации.
Шесть уязвимостей GitLab CISA отметило как эксплуатируемые с ноября 2021 года, включая две в феврале этого года. Это уже не статистический шум, а устойчивый сигнал для DevOps- и security-команд: уязвимость GitLab должна попадать в отдельный ускоренный процесс патчинга, а не растворяться среди обычных обновлений. Чем плотнее GitLab встроен в цепочку разработки и поставки, тем меньше права на ошибку у компании, которая оставляет критический сервер «до следующего планового окна».
