GitLab AI Gateway получил критическую уязвимость CVE-2026-90970 (CVSS 9.9), позволяющую аутентифицированному пользователю с доступом к Duo Agent Platform при определённых условиях выполнить произвольные команды на шлюзе; под угрозой находятся только организации с self-hosted AI Gateway, которые обязаны немедленно обновить шлюз до версий 19.2.4, 19.3.2 или 19.4.1, иначе они рискуют потерять контроль над JWT-ключами и каналами связи между GitLab и провайдерами моделей.
Технические детали уязвимости
Согласно официальному advisory GitLab по выпуску патча для AI Gateway версий 19.2.4, 19.3.2 и 19.4.1 (patch-release gitlab-ai-gateway-19-4-1), CVE-2026-90970 описана как критическая слабость в механизме шаблонов подсказок (prompt template) в пользовательских потоках (custom flow) Duo Agent Platform:
- Идентификатор: CVE-2026-90970 (критическая; CVSS 9.9 по сообщению GitLab, подтверждена записью CVE-проекта: запись CVE-2026-90970).
- Класс слабости: CWE-1336 (ошибки в шаблонизаторах и системах генерации кода; указано GitLab как общий класс и для февральского CVE-2026-1868).
- Тип воздействия: возможность «escape the prompt template sandbox» с последующим выполнением произвольных команд на AI Gateway.
- Требуемые права: аутентифицированный пользователь с доступом к Duo Agent Platform и возможностью создавать/изменять custom flow; дополнительных ролей в advisory не названо.
Суть проблемы — в том, что механизм шаблонов, который должен изолировать исполняемый контекст (песочница для prompt template), может быть обойдён через специально сконструированную конфигурацию потока. В терминах модели угроз это превращает пользовательское описание AI-потока в канал для инъекции конструкций, приводящих к выполнению команд на хост-среде шлюза.
GitLab подчёркивает, что эксплуатация ведёт именно к выполнению команд на AI Gateway, а не напрямую на GitLab-сервере. Однако в архитектуре self-hosted Duo AI Gateway этот компонент является доверенным посредником и содержит чувствительные элементы:
- на шлюзе хранятся ключи подписи JWT, используемых для обмена между GitLab и шлюзом (адресовано в документации по self-hosted Duo: GitLab Duo Self-Hosted);
- шлюз поддерживает соединения и с самим GitLab-инстансом, и с провайдерами моделей.
С точки зрения угроз это означает, что успешное выполнение команд на AI Gateway может привести как минимум к:
- компрометации JWT-ключей (потеря доверия ко всем токенам, подписанным этим шлюзом);
- возможности манипулировать трафиком между GitLab и провайдерами моделей (подмена запросов/ответов, утечка содержимого подсказок и кодовой базы, если они проходят через шлюз);
- использованию шлюза как точки опоры для дальнейшего продвижения по сети.
Запись о CVE в NVD, созданная на основе информации от GitLab и CVE-проекта, доступна по стандартному идентификатору CVE-2026-90970 в NVD, что закрепляет оценку как критическую и подтверждает удалённое выполнение кода (RCE) при наличии аутентификации.
Затронутые и исправленные версии
AI Gateway поставляется как отдельный компонент (Docker-образ или Helm chart) и обновляется независимо от основной версии GitLab. В advisory GitLab по AI Gateway (документация по установке и обновлению AI Gateway) фиксируются такие ключевые моменты:
- Исправленные версии AI Gateway:
- 19.2.4
- 19.3.2
- 19.4.1
- Нет исправлений для веток ниже 19.2.4, при этом в advisory явно указано, что все релизы от 18.1.6 до включая линию 19.1 подпадают под диапазон затронутых версий.
- GitLab поддерживает (по состоянию на 2 октября) только ветки GitLab 19.4, 19.3 и 19.2, что отражено в политике сопровождения: GitLab maintenance policy. Те же линии получили патчи AI Gateway.
Для обновления Docker-развёртывания GitLab рекомендует остановить и удалить текущий контейнер AI Gateway, затем загрузить и запустить образ с новым тегом (например, self-hosted-v19.4.1-ee). Для Helm-развёртываний достаточно изменить тег образа в настройках chart и применить обновление.
Организации, использующие GitLab.com, GitLab Dedicated или self-managed GitLab с хостингом AI Gateway на стороне GitLab, защищены автоматически: провайдер уже обновил свои шлюзы. Действия требуются только от владельцев self-hosted шлюзов.
Advisory подчёркивает два важных ограничения:
- GitLab не предоставляет обходных решений (workaround) для тех, кто пока не может обновить шлюз.
- Не описаны надёжные диагностические методы, по которым администратор мог бы однозначно определить факт прошлой эксплуатации уязвимости на своём шлюзе.
Согласно оценке CISA, добавленной к записи CVE 2 октября, статус эксплуатации — «none» (отсутствуют сведения о публичной эксплуатации или proof-of-concept). Но это моментальное состояние: класс уязвимости и высокая оценка CVSS делают её привлекательной целью, особенно после публикации деталей патча.
Повторяющийся класс уязвимостей в AI Gateway
В феврале GitLab уже устранял критическую проблему того же класса в AI Gateway — CVE-2026-1868, также с оценкой 9.9 и аналогичным вектором: crafted flow definition, приводящий к отказу в обслуживании или выполнению кода на шлюзе. Патч описан в отдельном advisory GitLab: patch-release gitlab-ai-gateway-18-8-1.
Обе уязвимости относятся к CWE-1336 — нарушениям безопасности в системах шаблонов. Последовательность из двух критических инцидентов за менее чем год указывает на то, что:
- механизм шаблонов для пользовательских потоков в Duo Agent Platform является высокорисковой частью архитектуры;
- традиционные методы тестирования (включая unit-тесты и стандартный безопасностный review) не покрывают все сценарии злоупотребления custom flow;
- для защиты подобных платформ с возможностью настройки AI-потоков необходим целенаправленный security review шаблонизаторов и строгие ограничения доступных конструкций.
Для потребителей это означает, что риск не ограничивается единичным CVE: сама модель предоставления мощных средств конфигурирования AI-потоков конечным пользователям требует от администраторов более аккуратной настройки прав и постепенного ввёртывания таких функций в критические процессы.
Оценка воздействия и профиль риска
Основная зона риска — организации, которые:
- разворачивают self-hosted GitLab AI Gateway в собственных средах;
- предоставляют доступ к Duo Agent Platform широкому кругу разработчиков и команд, а не ограниченному доверенному ядру;
- используют AI-функции GitLab (GitLab Duo) для работы с чувствительным кодом или данными (IP, конфиденциальные артефакты, внутренние модели).
При отсутствии обновления потенциальные последствия включают:
- Компрометация аутентификации и авторизации:
- злоумышленник, получивший доступ к шлюзу, может извлечь JWT-ключи либо манипулировать процессом выдачи токенов;
- в результате — возможность подделки доверенных взаимодействий между GitLab и AI Gateway.
- Утечка данных:
- доступ к содержимому запросов и ответов AI-моделей;
- косвенный доступ к кодовой базе и артефактам, если они участвуют в AI-потоках.
- Расширение периметра атаки:
- использование шлюза как точки входа для дальнейшего продвижения в инфраструктуре (перемещение к GitLab-серверу, базам данных, сетевым сегментам, в которых расположен gateway);
- переход от «внутренней» уязвимости (требуется авторизация в Duo Agent Platform) к сценарию, где скомпрометированный внутренний аккаунт приносит максимальный ущерб.
Нужно учитывать, что наличие аутентификации не делает уязвимость малозначимой: в типичной DevOps-среде права на создание custom flow часто имеют разработчики и инженеры, уже обладающие широкими возможностями. CVE-2026-90970 превратит любой скомпрометированный аккаунт с такими правами в прямой рычаг для захвата AI Gateway.
Практические рекомендации по реагированию
1. Немедленное обновление self-hosted AI Gateway
- Определите, используете ли вы self-hosted AI Gateway:
- проверьте документацию собственной инсталляции или следуйте разделу «self-hosted» в руководстве GitLab Duo: GitLab Duo Self-Hosted;
- если вы используете GitLab.com или GitLab Dedicated без собственного шлюза, данный шаг можно пропустить — шлюз уже обновлён GitLab.
- Определите текущую версию AI Gateway:
- для Docker — по тегу образа/контейнера;
- для Helm — по указанному тегу образа в values-файле chart.
- Если версия ниже 19.2.4, 19.3.2 или 19.4.1:
- для Docker:
- остановите и удалите работающий контейнер AI Gateway;
- загрузите новый образ с исправленным тегом (
self-hosted-v19.2.4-ee,self-hosted-v19.3.2-eeилиself-hosted-v19.4.1-ee— в зависимости от вашей ветки GitLab, см. инструкцию по обновлению); - запустите новый контейнер с теми же параметрами среды и сети.
- для Helm:
- обновите тег образа AI Gateway в конфигурации chart до одной из исправленных версий;
- примените обновление (
helm upgrade ...).
- для Docker:
2. Управление доступом к Duo Agent Platform
- Пересмотрите список пользователей, имеющих доступ к Duo Agent Platform и правам создания/редактирования custom flow.
- Сведите этот доступ к минимально необходимому набору ролей, особенно в средах с self-hosted AI Gateway.
- Временно ограничьте эксперименты с пользовательскими потоками в продуктивных средах до завершения обновления и дополнительной оценки рисков.
3. Постинцидентный анализ и мониторинг
Поскольку GitLab не предоставил готового способа проверки факта эксплуатации, имеет смысл провести расширенный анализ активности вокруг AI Gateway и Duo Agent Platform за период до обновления:
- проанализируйте журналы доступа к Duo Agent Platform:
- создание или модификацию нестандартных custom flow;
- подозрительные частые или сложные изменения в конфигурациях потоков;
- проверьте журналы контейнера или пода AI Gateway на предмет:
- нетипичных команд в системных логах;
- ошибок, связанных с выполнением шаблонов (exceptions в шаблонизаторе);
- подозрительных исходящих соединений к необычным хостам.
- если есть основания предполагать эксплуатацию:
- считайте JWT-ключи на шлюзе скомпрометированными;
- инициируйте процедуру ротации ключей и пересоздания доверенных связей между GitLab и AI Gateway.
4. Долгосрочные меры
- Внедрите практику раздельного развёртывания:
- отдельные среды для экспериментов с AI-потоками и для продуктивных AI-интеграций;
- отдельные экземпляры AI Gateway для особо чувствительных проектов при необходимости.
- Включите обновления AI Gateway в общий процесс управления патчами наравне с GitLab core:
- проверка актуальных advisory GitLab для AI Gateway;
- регулярная сверка с поддерживаемыми версиями в maintenance policy.
- Переоцените модель доверия к AI-компонентам:
- рассматривайте AI Gateway как высокочувствительный сервис с эквивалентной критичностью GitLab-серверу;
- ограничьте сетевой доступ к шлюзу и используйте отдельные сегменты сети и контроль межсетевого обмена.
Ключевой приоритет для владельцев self-hosted GitLab AI Gateway — в ближайшее время обновить шлюз до одной из исправленных версий (19.2.4, 19.3.2 или 19.4.1), затем пересмотреть права доступа к Duo Agent Platform и провести хотя бы базовый аудит журналов шлюза и custom flow за период до обновления.
