GitLab выпустила срочные обновления для CVE-2026-97229 — уязвимости максимальной критичности, позволяющей удалённо выполнить произвольный код на сервере без авторизации. Для команд, которые самостоятельно разворачивают GitLab, эта уязвимость GitLab означает вполне практичную задачу: проверить версию инстанса и обновить её до патченного релиза, пока конфигурация CI/CD не стала точкой входа в инфраструктуру.
Проблема обнаружена исследователем под ником joaxcar и передана через программу вознаграждений HackerOne, сообщает BleepingComputer. Ошибка находится в CI/CD Regular Expression Compiler — компоненте, который разбирает, компилирует и вычисляет регулярные выражения из конфигураций пайплайнов проектов. При специально сформированном регулярном выражении злоумышленник мог добиться переполнения целого числа; в определённых условиях это открывало путь к запуску произвольного кода непосредственно на GitLab-сервере.
Ключевой неприятный нюанс — отсутствие необходимости входить в систему. Неаутентифицированные RCE в DevSecOps-платформах опаснее обычных багов веб-интерфейса: GitLab часто связан с репозиториями, токенами доступа, реестрами контейнеров, раннерами и секретами CI/CD. Сам факт выполнения кода на хосте ещё не описывает весь масштаб инцидента, но даёт атакующему возможность двигаться дальше — в зависимости от настроек конкретной установки.
Исправления вошли в GitLab Community Edition и Enterprise Edition версий 19.2.8, 19.3.4 и 19.4.2. Уязвимы ветки 19.2 до 19.2.8, 19.3 до 19.3.4 и 19.4 до 19.4.2. GitLab.com уже работает на исправленной версии, а клиентам GitLab Dedicated предпринимать действия не требуется. Предупреждение адресовано прежде всего владельцам self-managed-инсталляций: компания прямо рекомендует перейти на один из указанных релизов немедленно.
Для российских команд это знакомый, но неприятный сюжет. GitLab нередко размещают внутри периметра именно ради контроля над исходным кодом и данными. Однако внутреннее размещение не заменяет управление обновлениями: публичный доступ, интеграции, VPN, ошибки в reverse proxy или скомпрометированная учётная запись могут превратить «внутренний» сервис в доступную цель. В случае CVE-2026-97229 полагаться на авторизацию нельзя уже по определению.
Практический минимум для администраторов — установить поддерживаемую патченную версию, убедиться, что обновление прошло на всех узлах, и проверить журналы GitLab и инфраструктурный мониторинг на аномалии. Отдельного внимания заслуживают изменения в файлах конфигурации пайплайнов и неожиданные задания CI/CD: именно обработка регулярных выражений в таких конфигурациях затронута уязвимостью. Если обновление требует согласованного окна, разумнее на это время ограничить создание и обработку недоверенных конфигураций, а не оставлять сервис в прежнем режиме до ближайшего планового релиза.
Это уже не первая заметная проблема GitLab в 2026 году. В январе компания исправила CVE-2026-0723, позволявшую обойти двухфакторную аутентификацию при знании идентификатора учётной записи. В сентябре была устранена CVE-2026-85706 максимальной критичности: она позволяла неаутентифицированному атакующему читать конфиденциальные данные, включая учётные данные и секреты. На следующий день после публикации патча американское агентство CISA внесло CVE-2026-85706 в каталог известных эксплуатируемых уязвимостей и потребовало от федеральных ведомств защитить системы за три дня.
У CISA с ноября 2021 года накопилось пять уязвимостей GitLab, которые использовались в атаках; среди них была и проблема, интересовавшая вымогательские группировки. Это не доказательство эксплуатации нынешней CVE-2026-97229, но достаточный повод не откладывать патч ради привычного «у нас GitLab никто не трогает». Платформой GitLab пользуются более 30 млн зарегистрированных пользователей, а среди её клиентов — свыше половины компаний из Fortune 100. Чем заметнее платформа, тем быстрее детали критических ошибок становятся предметом интереса не только исследователей.
Главный вопрос теперь не в том, насколько сложно воспроизвести переполнение в компиляторе регулярных выражений, а в скорости реакции владельцев self-managed GitLab. Уязвимость GitLab в компоненте CI/CD снова напоминает: цепочка поставки ПО начинается не с готового образа в registry, а с инфраструктуры, которая читает конфигурацию и запускает пайплайны. В таких системах обновления критических компонентов давно стоит считать не фоновым обслуживанием, а частью защиты исходного кода и секретов.