AI Gateway от GitLab позволил специально созданной конфигурации Flow вырваться из песочницы промптов

2 октября 2026 года GitLab выпустила критическое исправление для своего AI Gateway — промежуточного слоя, который передаёт запросы между экземпляром GitLab и языковыми моделями, к которым обращаются функции Duo, — присвоив ему обозначение CVE-2026-90970 и оценив его в 9,9 из 10. По словам самого GitLab, эта уязвимость могла позволить «аутентифицированному пользователю с доступом к Duo Agent Platform выйти из песочницы шаблонов промптов с помощью специально сконструированной конфигурации потока, что ведёт к выполнению произвольных команд на AI Gateway». Действовать требовалось только организациям, использующим самостоятельно размещённый AI Gateway: GitLab уже исправила шлюзы, которыми управляет сама, для GitLab.com, GitLab Dedicated и клиентов self-managed, использующих шлюз, размещённый GitLab, и сообщила об этом в рекомендации. В уведомлении GitLab не говорится, что уязвимость когда-либо эксплуатировалась, а оценка, приложенная к записи CVE Агентством по кибербезопасности и защите инфраструктуры США в тот же день, указывает статус эксплуатации как «none». Заслуга в обнаружении принадлежит исследователю HackerOne, известному под псевдонимом invisiblemeerkat. Рекомендация GitLab, запись в NVD и последовавшие за ней публикации согласуются друг с другом в отношении того, в чём заключалась уязвимость и какие версии были ей подвержены; они столь же согласованы и в отношении того, что остаётся неизвестным, а именно — использовал ли её кто-либо когда-нибудь. Эта запись соседствует с другими задокументированными уязвимостями агентской инфраструктуры в архиве инцидентов ИИ, где каждая запись содержит собственные источники, уровень серьёзности, степень уверенности и отметку об оспаривании.

Что на самом деле сказано в рекомендации и что в ней опущено

Уведомление короткое. Оно опубликовано на сайте документации GitLab под заголовком «Критический выпуск исправлений GitLab AI Gateway: 19.2.4, 19.3.2 и 19.4.1» и содержит одно исправление безопасности под заголовком «Проблема некорректной нейтрализации в шаблоне промпта пользовательского потока затрагивает AI Gateway», отмеченное как критическое. В нём указан вектор CVSS 3.1: AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H — доступность по сети, низкая сложность атаки, требуются низкие привилегии, взаимодействие с пользователем не требуется, область действия изменена, высокое воздействие на конфиденциальность, целостность и доступность. Этот вектор стоит прочитать, потому что он точно описывает атакующего: низкие привилегии, но всё же привилегии. В уведомлении сказано: «аутентифицированный пользователь с доступом к Duo Agent Platform», — и на этом всё. В нём не указаны ни роль, ни разрешение, ни условия, к которым относится его собственная фраза «при определённых условиях».

Он не публикует proof of concept, не описывает специально сформированную конфигурацию потока и не предлагает обходного решения для шлюзов, которые нельзя обновить немедленно. The Hacker News в своем отчете от 2 октября отмечает те же пробелы и добавляет один, важный с операционной точки зрения: в рекомендации не приводится способа проверить, подвергался ли шлюз атаке до того, как был исправлен. Security Affairs, написавшее на следующий день, фиксирует те же пробелы.

Запись перечисления распространённых слабостей, прикреплённая к CVE, — это CWE-1336 — неправильная нейтрализация специальных элементов, используемых в шаблонизаторе. В рекомендациях GitLab слово Jinja не используется ни разу. А вот в документации собственного репозитория AI Gateway оно есть: документ реестра промптов описывает файлы конфигурации промптов, которые «поддерживают выражения Jinja для нескольких ролей, таких как пользователь и система», и описывает класс Prompt, который «использует Jinja для интерполяции шаблонов промптов с помощью входных аргументов». Уязвимость, которую описывает CVE, — это именно та, которой знаменит этот класс движков: предоставленный пользователем текст попадает в шаблон, который вычисляется, а не выводится как есть.

Почему команда на этом конкретном хосте стоит 9,9

AI Gateway — это не сайдкар. Согласно документации GitLab по развертыванию на собственной инфраструктуре, он получает запросы от GitLab, собирает промпты и взаимодействует с бэкендом модели — сервером vLLM, Amazon Bedrock, Azure OpenAI или внешним провайдером — и при полностью самостоятельном развертывании именно этот компонент удерживает промпты и ответы внутри собственной сети организации. Руководство по установке AI Gateway от GitLab также предписывает администраторам сгенерировать пару ключей подписи и передать обе ее части сервису в качестве переменных среды: AIGW_SELF_SIGNED_JWT__SIGNING_KEY и AIGW_SELF_SIGNED_JWT__VALIDATION_KEY (с аналогичными переменными для Duo Workflow). Security Affairs прямо указывает на последствие: выполнение команд на шлюзе помещает злоумышленника на хост, где хранятся материалы для подписи JWT и который находится на пути между экземпляром GitLab и инфраструктурой моделей.

Вот в чём разница между выходом из песочницы в игрушечной системе и в продакшене. Выходу не нужно достигать модели; ему нужно достичь процесса, который хранит ключи, которыми подписываются вызовы модели.

В документации по продукту GitLab, отдельно от рекомендации, указано, что для создания или редактирования пользовательского потока требуется роль Maintainer или Owner в управляющем проекте, а для его запуска — Developer или выше. В рекомендации это соответствие не подтверждается, и The Hacker News отмечает, что не названа ни одна роль, кроме «доступа к Duo Agent Platform». Читателю, оценивающему собственную подверженность риску, следует рассматривать документацию как модель разрешений продукта, а молчание рекомендации — именно как молчание, а не как противоречие.

Установлено и не установлено

Собственные поля записи согласуются со всем вышесказанным и не добавляют ничего, чего нет в уведомлении. Далее приводится разбивка, которую читатель не получит из однострочного резюме.

• Установлено: уязвимость критической степени опасности в GitLab AI Gateway, раскрытая 2 октября 2026 года, CVSS 9.9, CWE-1336, доступная аутентифицированному пользователю Duo Agent Platform через специально сформированную конфигурацию потока и приводящая к выполнению команд на хосте шлюза.

• Установлено: затронутый диапазон — все версии AI Gateway от 18.1.6 до 19.2.4 (не включая 19.2.4), от 19.3 до 19.3.2 и от 19.4 до 19.4.1 — и исправленные версии: 19.2.4, 19.3.2 и 19.4.1.

• Установлено:Шлюзы, размещённые в GitLab, были исправлены до публикации, и их клиентам не нужно предпринимать никаких действий; с операторами самостоятельно развёрнутых систем связались напрямую до публикации сообщения о выпуске, о чём GitLab сообщает в самом уведомлении.

• Установлено: автор сообщения — invisiblemeerkat, а также отсутствие каких-либо заявлений об эксплуатации в реальных условиях.

• Не установлено: эксплуатировал ли её кто-либо. Оценка CISA SSVC от 2 октября 2026 г., видимая в записи NVD, указывает эксплуатацию как «нет», автоматизируемость как «нет», а техническое воздействие как «полное»; каталог CISA Known Exploited Vulnerabilities не содержал CVE-2026-90970 в редакции от 20 октября 2026 г., что я проверил непосредственно. Модель EPSS организации FIRST оценила вероятность эксплуатации в ближайшие 30 дней в 0,94 процента на 21 октября 2026 г. — низкую, но не нулевую.

• Не установлено: сколько существует шлюзов, развёрнутых на собственной инфраструктуре, сколько из них были открыты и подвергался ли какой-либо из них атаке до установки исправления. Ни один источник в этой записи не приводит количество, и уведомление GitLab не содержит метода обнаружения.

Затронутый диапазон и версии, для которых исправление не указано

Арифметика версий выглядит менее стройной, чем можно предположить по трём выпускам с исправлениями. Диапазон затронутых версий начинается с 18.1.6, и ни в одной ветке ниже 19.2.4 не опубликован исправленный выпуск. Поэтому каждый шлюз с 18.1.6 по ветку 19.1 включительно находится внутри заявленного диапазона затронутых версий, и для него не указана исправленная версия. The Hacker News отмечает то же следствие и вопросы, которые за ним следуют: документация GitLab по установке предписывает администраторам запускать образ шлюза, версия которого соответствует их минорной версии GitLab, а в рекомендации не сказано, работает ли шлюз 19.2.4 с GitLab 19.1 или более ранней версией и планируются ли исправления для старых веток. Политика GitLab в отношении поддерживаемых версий, как отмечает The Hacker News, в настоящее время включает 19.4, 19.3 и 19.2 — те же три ветки, которые получили исправления.

Устранение уязвимости выполняется путем замены контейнера, а не установки патча: шлюз поставляется как отдельный Docker-образ или Helm-чарт. В руководстве по установке GitLab описано, как остановить и удалить работающий контейнер, загрузить новый образ с тегом self-hosted-vX.Y.Z-ee и снова запустить его с сохранением переменных среды; при развертываниях через Helm тег задается в поле image чарта. Ни в уведомлении, ни в руководстве по установке не приводится подпись или индикатор, по которому можно было бы отличить атакованный шлюз от чистого.

Тот же класс ошибок, восемь месяцев назад

Это не первый раз, когда GitLab присваивает оценку 9.9 за внедрение шаблонов в AI Gateway. 6 февраля 2026 года компания выпустила AI Gateway 18.6.2, 18.7.1 и 18.8.1 для CVE-2026-1868, описанной в том бюллетене как «проблема небезопасного расширения шаблонов» (Insecure Template expansion issue), в которой компонент Duo Workflow Service был «уязвим к небезопасному расширению шаблонов пользовательских данных через специально сформированные определения Duo Agent Platform Flow», что позволяло использовать её для отказа в обслуживании или выполнения кода на шлюзе. Вектор CVSS идентичен октябрьскому, символ в символ, как и CWE. Обнаружил её другой человек: ту уязвимость нашли внутри компании, участник команды GitLab Joern Schneeweisz.

В октябрьском уведомлении об уязвимости не упоминается февральское, и The Hacker News прямо об этом говорит. Общая ли у них первопричина, не сработавшее исправление или всего лишь язык и модель угроз — ни один из двух публичных документов не отвечает на это. Что документально зафиксировано: шаблонизатор в компоненте промежуточного ПО для ИИ уже привёл к появлению двух критических уведомлений об уязвимостях, связанных с выполнением команд, с одинаковой оценкой в одном и том же году, а для обнаружения второго потребовался сторонний исследователь.

Что изменилось и что остаётся решать операторам

Конкретное изменение — это три тега образов и раунд адресного информирования. GitLab сообщает, что связалась с клиентами, использующими самостоятельно размещённый шлюз, до публикации, а уведомление было выпущено вместе с исправленными образами в тот же день. Для всех остальных — GitLab.com, GitLab Dedicated и самостоятельно управляемых экземпляров, настроенных на шлюз, размещённый GitLab, — исправление уже было применено на стороне сервера, и, по словам GitLab, ничего не требовалось.

Для оператора самостоятельно размещённой системы это решение уже́ и менее комфортно, чем обычный цикл выпуска исправлений. Для шлюза, который нельзя перенести немедленно, обходного пути нет. Не существует выпущенного способа установить, был ли хост скомпрометирован ранее, а значит, единственный ретроспективный вариант — обычный: рассматривать контейнер как систему с недоказанной целостностью и искать признаки выполнения, выходящего за рамки её нормального поведения. А для шлюзов на 18.x или 19.1 в рекомендациях вообще не указана целевая версия — это упущение, о котором сообщает The Hacker News и которое не рассматривается в уведомлении GitLab.

Собственная классификация архива намеренно уже, чем у вендора. Он фиксирует эту запись как уязвимость с уровнем уверенности A, при согласии источников и без разногласий, без зафиксированного реального ущерба и с полем важности «high» против «critical» у GitLab и NVD. Это ответы на разные вопросы: оценка описывает, что позволяла бы уязвимость, а оценка архива описывает, что, как известно, произошло. Согласно публичным данным, не произошло ничего — ни эксплуатации, ни пострадавших, ни отчёта об инциденте. Ценность записи в том, что она документирует — с номером CVE и исправленной версией — как именно шаблон промпта превратился в командную строку в промежуточном ПО, от которого зависят корпоративные ИИ-функции.