Уязвимость GitLab RCE с максимальной оценкой CVSS 10 из 10 затрагивает self-managed-инсталляции, выпущенные за последние 12 лет. Ошибка позволяет неаутентифицированному атакующему при определённых условиях выполнить произвольный код на сервере — а для GitLab это потенциально означает доступ не только к репозиториям, но и к CI/CD, токенам и секретам развёртывания.
Проблема получила идентификатор CVE-2026-110264 и связана с целочисленным переполнением при компиляции специально сформированного регулярного выражения. Как сообщает The Register, под ударом оказались GitLab Community Edition и Enterprise Edition, включая ветку GitLab 7.0, вышедшую в июне 2014 года. Вендор выпустил обновления и настоятельно рекомендует администраторам установить исправленную версию как можно быстрее.
Патчи вошли в GitLab 19.5.1, 19.4.3 и 19.3.6. Исправление также перенесли в поддерживаемые более ранние ветки: 19.2.9, 19.1.9, 19.0.10 и 18.11.13. Это важная деталь для компаний, которые не могут перейти на свежий минорный релиз одним рывком из-за собственных интеграций, регламентов или тяжёлых пайплайнов: безопасный маршрут обновления есть не только для последней версии.
Ошибка найдена исследователем Йоханом Карлссоном через программу bug bounty GitLab на HackerOne. Формулировка в бюллетене не означает, что любой открытый GitLab-сервер гарантированно взламывается одним HTTP-запросом: для эксплуатации нужны описанные вендором условия и подготовленное регулярное выражение. Но сочетание трёх факторов — отсутствие необходимости входить в систему, удалённое выполнение кода и десятилетняя глубина затронутых выпусков — объясняет максимальную оценку серьёзности.
GitLab.com и GitLab Dedicated, которыми управляет сам GitLab, уже защищены. Риск относится прежде всего к самостоятельно развёрнутым экземплярам: корпоративным GitLab в дата-центрах, частных облаках и изолированных контурах. Вендор дополнительно опубликовал два правила обнаружения угроз для клиентов с self-managed-инфраструктурой. Их стоит рассматривать как дополнение к обновлению и проверке журналов, а не как замену патчу: после публичного исправления злоумышленники обычно быстро разбирают изменения в коде и начинают искать доступные цели.
Для российских команд это не история только про сервер контроля версий. В типичной установке GitLab сходятся исходный код, CI-конфигурации, ключи доступа, переменные окружения, контейнерные реестры и описания инфраструктуры. Компрометация сервера может дать атакующему возможность украсть учётные данные, изменить репозиторий или pipeline, закрепиться в сети и добраться до production через уже доверенные механизмы поставки. Иными словами, уязвимость GitLab RCE может превратить внутренний DevOps-инструмент в удобную точку входа в инфраструктуру.
Практический минимум для команд выглядит прозаично, но именно в этом случае он важнее эффектных мер: определить все self-managed-инсталляции GitLab, сопоставить их версии со списком исправленных релизов и обновить серверы. Параллельно имеет смысл проверить, не был ли GitLab непреднамеренно опубликован в интернете через старый балансировщик, тестовый домен или временное правило firewall. После обновления разумно посмотреть логи на необычные запросы, ошибки обработки регулярных выражений, новые токены, изменения в CI/CD-настройках и подозрительные задания, запускавшиеся от сервисных учётных записей.
Инцидент укладывается в неприятный, но знакомый паттерн: критические баги в системах разработки быстро становятся приоритетной целью, потому что одна успешная атака открывает путь сразу к коду и цепочке поставки. В прошлом месяце атакующие начали эксплуатировать другую уязвимость максимальной критичности в GitLab CE и EE спустя считаные дни после выхода патча. Пока нет данных об атаках через CVE-2026-110264, однако окно спокойствия для не обновившихся серверов вряд ли будет долгим.
