CVE-2026-90970 в GitLab AI Gateway: ризик RCE та компрометації JWT-ключів

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 і провайдерами моделей.

Технічні деталі вразливості

Згідно з офіційним бюлетенем безпеки 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; додаткові ролі в бюлетені безпеки не названі.

Суть проблеми полягає в тому, що механізм шаблонів, який має ізолювати виконуваний контекст (пісочниця для 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. У бюлетені безпеки GitLab щодо AI Gateway (документація по встановленню та оновленню AI Gateway) фіксуються такі ключові моменти:

• Виправлені версії AI Gateway:
  • 19.2.4
  • 19.3.2
  • 19.4.1
• Немає виправлень для гілок нижче 19.2.4, при цьому в бюлетені безпеки прямо зазначено, що всі релізи від 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 шлюзів.

Бюлетень безпеки підкреслює два важливі обмеження:

• GitLab не надає тимчасові рішення (workaround) для тих, хто поки не може оновити шлюз.
• Не описано надійні діагностичні методи, за якими адміністратор міг би однозначно визначити факт минулої експлуатації вразливості на своєму шлюзі.

Згідно з оцінкою CISA, доданою до запису CVE 2 жовтня, статус експлуатації — «none» (відсутні відомості про публічну експлуатацію або proof-of-concept). Але це стан на поточний момент: клас вразливості та висока оцінка CVSS роблять її привабливою ціллю, особливо після публікації деталей патча.

Повторюваний клас вразливостей в AI Gateway

У лютому GitLab уже усував критичну проблему того самого класу в AI Gateway — CVE-2026-1868, також з оцінкою 9.9 і подібним вектором: crafted flow definition, що призводить до відмови в обслуговуванні або виконання коду на шлюзі. Патч описаний в окремому бюлетені безпеки GitLab: patch-release gitlab-ai-gateway-18-8-1.

Обидві вразливості належать до CWE-1336 — порушень безпеки в системах шаблонів. Послідовність із двох критичних інцидентів менш ніж за рік вказує на те, що:

• механізм шаблонів для користувацьких потоків у Duo Agent Platform є високоризиковою частиною архітектури;
• традиційні методи тестування (включно з unit-тестами та стандартним переглядом безпеки) не покривають усі сценарії зловживання 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

1. Визначте, чи використовуєте ви self-hosted AI Gateway:
   • перевірте документацію власної інсталяції або дотримуйтесь розділу «self-hosted» у посібнику GitLab Duo: GitLab Duo Self-Hosted;
   • якщо ви використовуєте GitLab.com або GitLab Dedicated без власного шлюзу, цей крок можна пропустити — шлюз уже оновлено GitLab.
2. Визначте поточну версію AI Gateway:
   • для Docker — за тегом образу/контейнера;
   • для Helm — за вказаним тегом образу у values-файлі chart.
3. Якщо версія нижча за 19.2.4, 19.3.2 або 19.4.1:
   • для Docker:
     1. зупиніть і видаліть запущений контейнер AI Gateway;
     2. завантажте новий образ з виправленим тегом (self-hosted-v19.2.4-ee, self-hosted-v19.3.2-ee або self-hosted-v19.4.1-ee — залежно від вашої гілки GitLab, див. інструкцію з оновлення);
     3. запустіть новий контейнер з тими самими параметрами середовища й мережі.
   • для Helm:
     1. оновіть тег образу AI Gateway в конфігурації chart до однієї з виправлених версій;
     2. застосуйте оновлення (helm upgrade ...).

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;
  • підозріло часті або складні зміни в конфігураціях потоків;
• перевірте журнали контейнера або pod’а AI Gateway на предмет:
  • нетипових команд у системних логах;
  • помилок, пов’язаних із виконанням шаблонів (exceptions у шаблонізаторі);
  • підозрілих вихідних з’єднань до нетипових хостів.
• якщо є підстави припускати експлуатацію:
  • вважайте JWT-ключі на шлюзі скомпрометованими;
  • ініціюйте процедуру ротації ключів і пересоздання довірених зв’язків між GitLab і AI Gateway.

4. Довгострокові заходи

• Упровадьте практику роздільного розгортання:
  • окремі середовища для експериментів з AI-потоками та для продуктивних AI-інтеграцій;
  • окремі екземпляри AI Gateway для особливо чутливих проєктів за потреби.
• Включіть оновлення AI Gateway до загального процесу керування патчами нарівні з GitLab core:
  • перевірка актуальних бюлетенів безпеки 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 за період до оновлення.