Защита GitLab AI Gateway от удаленного выполнения кода

Крупные предприятия тратят миллионы на изоляцию своих рабочих нагрузок ИИ за частными брандмауэрами и шлюзами с собственным хостингом. Они ожидают полного контроля над потоком данных и укрепленного периметра против внешних угроз. Фактическая эксплуатируемость GitLab AI Gateway версии 19.4 показывает, что даже самые изолированные среды остаются уязвимыми для простых ошибок ввода. Один авторизованный пользователь с доступом к платформе Duo Agent может обойти песочницу, которая должна ограничивать промпты ИИ. Этот побег ведет напрямую к выполнению произвольных команд на сервере, управляющем подключением организации к большим языковым моделям.

Я потратил годы, анализируя то, как разработчики относятся к шаблонизаторам как к безопасным зонам. Существует распространенное заблуждение, что если пользователь уже аутентифицирован, риск побега из песочницы вторичен. Такое мышление опасно. В случае с CVE-2026-90970 GitLab оценила уязвимость в 9,9 балла из 10 по шкале CVSS. Этот балл является четким индикатором того, что сообщество безопасности рассматривает это как критический сбой. Ошибка заключается не в тонком повреждении памяти или сложной атаке по времени. Это сбой в шаблоне промпта пользовательского потока — функции, предназначенной для автоматизации многоэтапных задач.

Архитектурный риск конфиденциальных ключей подписи

GitLab AI Gateway действует как небьющееся цифровое хранилище для соединения между внутренним экземпляром GitLab и внешними провайдерами ИИ. По задумке, этот шлюз хранит ключи подписи JSON Web Tokens (JWT). Эти ключи являются конфиденциальными учетными данными, обеспечивающими безопасную связь. Если злоумышленник выполняет команды на шлюзе, он перестает быть просто пользователем внутри песочницы. Он обладает теми же правами, что и сама служба шлюза. Такой уровень доступа позволяет злоумышленнику перехватывать запросы или потенциально манипулировать ответами ИИ, на которые полагаются другие разработчики компании для генерации кода и сканирования безопасности.

С точки зрения рисков, последствия носят системный характер. Self-hosted шлюз часто выбирают именно для того, чтобы удерживать данные внутри контролируемой среды. Когда такой шлюз скомпрометирован, инструмент, призванный повысить конфиденциальность, сам становится плацдармом для более масштабного вторжения. Шлюз подключается к провайдерам моделей ИИ организации и к основному экземпляру GitLab. Компрометация здесь — это компрометация доверительных отношений между средой разработки и интеллектуальным уровнем, который ее обеспечивает.

Деконструкция побега из песочницы через инъекцию промпта

Техническая реальность этой уязвимости кроется в CWE-1336, которая охватывает ненадлежащую нейтрализацию директив в шаблонах веб-страниц. GitLab позволяет пользователям создавать пользовательские потоки на платформе Duo Agent. Эти потоки используют шаблоны промптов для структурирования того, как ИИ обрабатывает информацию. Пользователь с легитимным доступом может создать конфигурацию потока, которая обманом заставит шаблонизатор выполнить код за пределами намеченных границ. Это классический побег из песочницы. Система воспринимает вредоносный ввод злоумышленника как команду, а не как данные.

За кулисами шлюз не может должным образом проверить структуру шаблона промпта. Я помню похожий случай, который обсуждал с «белым» хакером через Signal в прошлом году. Мы рассматривали шаблонизатор, который позволял пользователям вызывать системные функции, если они вкладывали скобки определенным образом. Это была простая оплошность в парсере. Недавняя история GitLab предполагает, что это повторяющаяся тема. В феврале они исправили CVE-2026-1868, еще одну уязвимость с рейтингом 9,9, которая также была связана с подготовленными определениями потоков. Повторение этого класса уязвимостей указывает на то, что безопасность шаблонов остается сложным препятствием для платформ с интеграцией ИИ.

Оценка поверхности атаки для self-hosted экземпляров

Действовать нужно только тем организациям, которые хостят собственный AI Gateway. GitLab управляет шлюзом для клиентов на GitLab.com и GitLab Dedicated. Говоря проактивно, эти клиенты уже защищены, так как GitLab обновила свою инфраструктуру до публикации официальных рекомендаций. Бремя защиты теперь ложится на плечи системных администраторов, которые управляют собственными образами Docker или Helm-чартами.

На архитектурном уровне шлюз является автономной службой. Он не обновляется автоматически при обновлении основного экземпляра GitLab. Это разделение важно. Распространенная ошибка — полагать, что исправленное приложение GitLab Rails означает исправленную среду ИИ. Шлюз — это отдельный Docker-образ со своей версией и жизненным циклом. Если вы используете версию между 18.1.6 и 19.2.4 или любую версию в линейках 19.3 и 19.4 до последних выпусков, вы уязвимы.

Инструкции по ручному обновлению для Docker и Helm

Патчинг — единственная эффективная мера противодействия, так как GitLab не предоставила обходного пути. Чтобы обезопасить развертывание на базе Docker, необходимо остановить существующий контейнер и удалить его. Затем вы загружаете обновленный тег образа. Для большинства корпоративных пользователей это будет тег self-hosted-v19.4.1-ee или его эквивалент для линеек 19.2 и 19.3.

Для тех, кто использует Kubernetes, процесс включает обновление настроек образа в Helm-чарте. В таблице ниже приведены необходимые пути обновления для затронутых версий:

Политика обслуживания GitLab обычно охватывает текущий и два предыдущих минорных релиза. Следовательно, исправления доступны для линеек 19.2, 19.3 и 19.4. Если вы используете более старую версию, например 19.1, официального исправления не существует. Отсутствие поддержки старых версий — это важная деталь, которую администраторы не должны упускать из виду. Использование неподдерживаемой версии шлюза фактически означает, что цифровое хранилище остается открытым.

Форензика и отсутствие эксплуатации

На сегодняшний день Агентство по кибербезопасности и инфраструктурной безопасности США (CISA) указывает статус эксплуатации этой уязвимости как «отсутствует». Публичного доказательства концепции (PoC) и свидетельств активной эксплуатации в дикой природе нет. Однако в рекомендации не указан метод проверки того, был ли шлюз атакован до обновления. Это отсутствие форензической видимости является значительным пробелом. Без специфических сигнатур логов или индикаторов компрометации администраторам остается только гадать, был ли получен доступ к их ключам подписи в период уязвимости.

В случае взлома подобного инструмента целью часто является скрытое закрепление в системе. Злоумышленник может не обрушивать шлюз. Вместо этого он может незаметно экспортировать ключи подписи JWT, чтобы облегчить несанкционированный доступ к моделям ИИ позже. Вот почему немедленная ротация конфиденциальных учетных данных после патча является стандартной отраслевой практикой. Заделывание пробоины в корпусе корабля — это первый шаг, но вы также должны проверить, не был ли выброшен какой-либо груз за борт, пока дыра была открыта.

Человеческий фактор в безопасности ИИ

Мы часто воспринимаем ИИ как футуристический слой, который надстраивается над нашим существующим кодом. На самом деле сервисы ИИ, такие как GitLab Gateway, — это просто еще одно программное обеспечение. Они подвержены тем же старым уязвимостям, таким как инъекция команд и побеги из шаблонов. Человеческий брандмауэр остается первой линией защиты. Пользователи, имеющие доступ к платформе Duo Agent, — это те, кто может добраться до этой уязвимости. Ограничение доступа к этим платформам только теми, кому это строго необходимо, соответствует принципу наименьших привилегий.

Zero Trust — это вышибала в VIP-клубе у каждой внутренней двери. Даже если пользователь находится внутри здания, вышибала должен проверить его полномочия, прежде чем подпустить к конфигурации шаблонизатора. Если ваша организация позволяет каждому разработчику создавать пользовательские потоки ИИ без надзора, вы увеличиваете поверхность атаки. Сложность этих интеграций ИИ делает детальный контроль доступа обязательным требованием, а не просто предложением.

Выводы для немедленного смягчения последствий

Чтобы устранить эту критическую уязвимость, администраторы должны выполнить определенную последовательность действий. Во-первых, определите точную версию образа AI Gateway, запущенного в данный момент в среде. Не предполагайте, что версия совпадает с основным приложением GitLab. Во-вторых, немедленно примените соответствующий патч, используя процедуры Docker или Helm, предоставленные GitLab. В-третьих, рассмотрите возможность ротации ключей подписи JWT, если шлюз был доступен недоверенным внутренним пользователям до применения патча.

Наконец, проведите аудит списка пользователей, имеющих разрешение на настройку пользовательских потоков на платформе Duo Agent. Если у пользователя нет критически важной причины для изменения этих конфигураций, закройте ему доступ. Сокращение числа людей, которые могут добраться до уязвимости, так же важно, как и исправление самого кода. Безопасность — это непрерывный процесс совершенствования, а не разовое обновление.

Источники

• GitLab Security Advisory (CVE-2026-90970)
• CISA Known Exploited Vulnerabilities Catalog (Assessment Phase)
• CWE-1336: Improper Neutralization of Directives in Web Page Templates
• NIST Guide to Enterprise Patch Management Strategies

Отказ от ответственности: Данная статья предназначена только для информационных и образовательных целей. Она не заменяет профессиональный аудит кибербезопасности или услуги по реагированию на инциденты. Всегда консультируйтесь с официальной документацией вендора перед выполнением обновлений системы.