GitLab выпустила патчи для критической уязвимости в AI Gateway — сервисе, который связывает инсталляцию GitLab с моделями ИИ. Дыра получила идентификатор CVE-2026-90970 и оценку 9.9 из 10 по шкале CVSS. Обновляться нужно только тем организациям, которые разворачивают шлюз у себя: на GitLab.com, в GitLab Dedicated и в self-managed инсталляциях с шлюзом, размещённым самим GitLab, делать ничего не требуется — там проблему уже закрыли.
Что именно ломается
По данным advisory, уязвимость кроется в шаблоне промпта пользовательского потока (custom flow) — сценария на платформе Duo Agent Platform, которым пользователи автоматизируют многошаговые задачи. Вошедший в систему пользователь с доступом к Duo Agent Platform мог через специально составленную конфигурацию потока выйти из песочницы шаблона промпта и добраться до выполнения произвольных команд на шлюзе.
Какие именно условия нужны для атаки, в advisory не описано; конкретная роль пользователя, кроме наличия доступа к Duo Agent Platform, тоже не названа. Это важно, потому что self-hosted шлюз хранит ключи подписи для JSON Web Token (JWT) — установочное руководство GitLab предписывает обращаться с ними как с чувствительными учётными данными. Кроме того, шлюз подключён и к самой инсталляции GitLab, и к провайдерам моделей ИИ, которыми пользуется организация.
Уязвимость обнаружил исследователь под ником invisiblemeerkat, сообщивший о ней через HackerOne.
Какие версии закрыты
Речь идёт о версиях самого AI Gateway, а не GitLab. Шлюз ставится отдельным Docker-образом или Helm-чартом и обновляется по собственным инструкциям.
| Версия шлюза | Первая исправленная версия |
|---|---|
| 18.1.6 и новее, до 19.2.4 | 19.2.4 |
| 19.3, до 19.3.2 | 19.3.2 |
| 19.4, до 19.4.1 | 19.4.1 |
Исправленной версии ниже 19.2.4 в списке нет. Это значит, что весь диапазон выпусков от 18.1.6 до линии 19.1 включительно остаётся в зоне уязвимости. Руководство по установке советует администраторам брать образ шлюза, совпадающий с минорной версией GitLab. Работает ли шлюз 19.2.4 с GitLab 19.1 или более старым и планируются ли исправления для старых линий, в advisory не сказано.
На 2 октября политика сопровождения GitLab относила к получающим исправления безопасности релизам 19.4, 19.3 и 19.2 — те же три линии, для которых вышел патч шлюза.
Как обновиться
Для Docker-развёртывания нужно остановить и удалить работающий контейнер, затем получить и запустить новый образ с нужным тегом, например self-hosted-v19.4.1-ee. В Helm-развёртываниях новый тег прописывается в настройке образа чарта.
Обходного пути для шлюзов, которые пока нельзя обновить, в advisory нет. Способа проверить, атаковали ли шлюз до обновления, там тоже не приводится.
Эксплуатации пока не зафиксировано
Использовалась ли уязвимость в атаках, в advisory не говорится. Агентство по кибербезопасности и защите инфраструктуры США (CISA) 2 октября добавило в запись CVE свою оценку, указав эксплуатацию как «none» — отсутствует. Два других значения, которые использует CISA, описывают публичный proof-of-concept и активную эксплуатацию.
Это не первый случай, когда GitLab правит критическую дыру в шлюзе. В феврале компания закрыла CVE-2026-1868, тоже с оценкой 9.9: вошедший пользователь мог добраться до неё через специально составленное определение потока, что вело к отказу в обслуживании или выполнению кода на шлюзе. Обе уязвимости относятся к одному классу слабостей шаблонизаторов — CWE-1336. В новом advisory февральская дыра не упоминается.
Если вы держите GitLab на своих серверах, стоит освежить в памяти и другие недавние критические истории: path traversal в GitLab с CVSS 10, который позволял читать любые файлы без входа, и уязвимость в GraphQL без аутентификации. Обе показывают, что периметр self-managed GitLab — цель постоянного внимания исследователей, и обновление шлюза здесь лишь один пункт из регулярного цикла патчей.
GitLab в России: проверьте, не поднят ли шлюз локально
GitLab — один из самых распространённых инструментов разработки в российских компаниях, и часть команд держит его на собственных серверах. Ключевой вопрос здесь не в том, какая у вас версия GitLab, а в том, разворачивали ли вы AI Gateway самостоятельно. Если шлюз размещён у GitLab, обновление уже сделано за вас. Если вы поднимали его сами — например, чтобы запросы и ответы к моделям ИИ не покидали ваш контур, — патч нужно ставить немедленно: именно такой шлюз хранит ключи подписи JWT и имеет доступ к провайдерам моделей.
Частые вопросы
Кого касается эта уязвимость?
Только организации, которые разворачивают AI Gateway самостоятельно. Пользователям GitLab.com, GitLab Dedicated и self-managed инсталляций со шлюзом, размещённым самим GitLab, обновляться не нужно — там исправление уже применено.
Что нужно, чтобы проэксплуатировать дыру?
Вошедший в систему пользователь с доступом к Duo Agent Platform и специально составленная конфигурация пользовательского потока. Остальные условия атаки в advisory не раскрыты.
До какой версии нужно обновиться?
До 19.2.4, 19.3.2 или 19.4.1 — в зависимости от вашей линии. Для выпусков ниже 19.2.4 исправленной версии не указано.
Уязвимость уже используют в атаках?
Нет данных об эксплуатации. CISA 2 октября указала в записи CVE значение «none» — эксплуатация отсутствует.
Есть ли обходной путь, если обновиться прямо сейчас нельзя?
В advisory обходных путей нет. Единственная рекомендация — обновиться как можно скорее.
Как понять, что мой шлюз атаковали?
Способа проверить это до обновления в advisory не приводится. Стоит исходить из того, что шлюз хранит ключи подписи JWT, и при подозрении на компрометацию считать эти ключи скомпрометированными.
Чем эта уязвимость отличается от февральской?
Ничем по классу: обе — CWE-1336, слабость шаблонизатора, и обе оценены в 9.9. Февральская CVE-2026-1868 также позволяла вошедшему пользователю через составленное определение потока вызвать отказ в обслуживании или выполнение кода на шлюзе.
Нужно ли обновлять сам GitLab, а не только шлюз?
Нет, патч касается версий AI Gateway. Шлюз ставится отдельным Docker-образом или Helm-чартом и обновляется по своим шагам, независимо от обновления инсталляции GitLab.
Источник: thehackernews.com