Faille critique CVSS 9.9 dans GitLab AI Gateway : exécution de commande sur les serveurs auto-hébergés

Aurélien Fontevive

Le 2 octobre 2026, GitLab a divulgué une vulnérabilité notée 9.9 sur 10 dans son AI Gateway, permettant à un utilisateur authentifié disposant d’un accès à la plateforme Duo Agent d’exécuter des commandes arbitraires sur la passerelle. Cette faille critique, identifiée sous le code CVE-2026-90970, touche uniquement les organisations qui hébergent elles-mêmes leur AI Gateway. Les instances GitLab.com, GitLab Dedicated et les instances auto-gérées utilisant la passerelle hébergée par GitLab ne sont pas concernées. Dans cet article, nous détaillons la nature de la vulnérabilité, les versions impactées, la procédure de mise à jour et les bonnes pratiques pour sécuriser vos déploiements DevOps.

Détails de la vulnérabilité CVE-2026-90970

Qu’est-ce que l’AI Gateway de GitLab ?

L’AI Gateway est le composant qui fait le lien entre une instance GitLab et les modèles d’intelligence artificielle (IA). Il permet aux utilisateurs d’intégrer des workflows alimentés par l’IA, notamment via la Duo Agent Platform. Les organisations qui hébergent leur propre passerelle conservent les données d’échange (requêtes/réponses) en interne, un choix souvent dicté par des impératifs de confidentialité ou de conformité (RGPD, etc.).

Comment la faille s’exprime-t-elle ?

Selon le bulletin de sécurité de GitLab, la vulnérabilité se situe dans le template de prompt d’un custom flow (workflow personnalisé). Un utilisateur disposant d’un accès à la plateforme Duo Agent peut, via une configuration de flux spécialement conçue, « s’échapper du bac à sable du template de prompt » et parvenir à une exécution de commande arbitraire sur la passerelle. GitLab classe cette faiblesse sous la catégorie CWE-1336 (Template Injection), une classe de failles déjà exploitée dans le passé sur d’autres plateformes.

« A logged-in user with Duo Agent Platform access could have used the flaw to escape the prompt template sandbox via a specially crafted flow configuration. » - GitLab Advisory, octobre 2026.

L’impact est maximal pour les organisations hébergeant leur AI Gateway : l’attaquant peut exécuter des commandes système, compromettre les clés de signature JWT (JSON Web Tokens) stockées sur la passerelle, et potentiellement pivoter vers le réseau interne ou les fournisseurs de modèles d’IA connectés.

Conditions d’exploitation

GitLab ne précise pas le niveau de privilège exact nécessaire, au-delà de l’accès à la Duo Agent Platform. Il n’existe à ce jour aucune preuve d’exploitation active selon l’évaluation de la Cybersecurity and Infrastructure Security Agency (CISA), qui a inséré une note le 2 octobre 2026 indiquant « exploitation : aucune » et « preuve de concept publique : non ». Toutefois, la gravité de la note CVSS 9.9 et l’absence de contournement connu imposent une mise à jour immédiate.

Versions concernées et correctifs

Les versions vulnérables couvrent toutes les publications de l’AI Gateway à partir de la version 18.1.6 jusqu’aux versions précédant les correctifs. GitLab a publié des versions corrigées pour trois lignes de support :

Version de l’AI Gateway utiliséePremière version corrigée
18.1.6 ou ultérieure, antérieure à 19.2.419.2.4
19.3, antérieure à 19.3.219.3.2
19.4, antérieure à 19.4.119.4.1

Aucune version antérieure à 18.1.6 ni de correctif pour les lignes 19.1 ou inférieures n’a été fournie. GitLab recommande de mettre à jour la passerelle vers une version correspondant à la version majeure/mineure de votre instance GitLab (par exemple, pour GitLab 19.4, utiliser la gateway 19.4.1).

Remarque : La politique de maintenance de GitLab au 2 octobre 2026 liste les versions 19.4, 19.3 et 19.2 comme seules lignes recevant des correctifs de sécurité. Les utilisateurs de versions antérieures doivent d’abord migrer vers une version supportée avant d’appliquer le correctif.

Procédure de mise à jour pour les instances auto-hébergées

Si vous hébergez votre propre AI Gateway, deux cas de figure se présentent selon la méthode de déploiement : Docker ou Helm.

Mise à jour sous Docker

  1. Identifier le tag de l’image actuelle : docker inspect gitlab-ai-gateway | grep image
  2. Arrêter et supprimer le conteneur en cours :
    docker stop gitlab-ai-gateway
docker rm gitlab-ai-gateway
  3. Tirer la nouvelle image :
    docker pull gitlab/ai-gateway:self-hosted-v19.4.1-ee   # adapter selon votre version GitLab
  4. Lancer le conteneur avec les mêmes paramètres (volumes, réseau, variables d’environnement) :
    docker run -d --name gitlab-ai-gateway [...] gitlab/ai-gateway:self-hosted-v19.4.1-ee
  5. Vérifier que le service répond : curl http://localhost:<port>/health

Mise à jour sous Helm (Déploiement Kubernetes)

  1. Modifier le fichier de valeurs Helm : mettre à jour l’entrée image.tag pour pointer vers le tag corrigé (ex. self-hosted-v19.4.1-ee).
  2. Appliquer les changements :
    helm upgrade gitlab-ai-gateway ./chart --values values.yaml
  3. Surveiller le déploiement : kubectl rollout status deployment gitlab-ai-gateway

Attention : GitLab précise qu’aucun workaround (contournement) n’est disponible. La seule action efficace est la mise à jour.

Recommandations de sécurité et bonnes pratiques

Réduction des risques en attendant le correctif

Si vous ne pouvez pas mettre à jour immédiatement, limitez l’exposition :

  • Restreignez l’accès au réseau de l’AI Gateway aux seules adresses IP de confiance (filtrage réseau / pare-feu).
  • Désactivez temporairement la Duo Agent Platform si elle n’est pas indispensable.
  • Auditez les custom flows existants : supprimez ceux qui ne sont plus utilisés ou qui n’ont pas été créés par des administrateurs.
  • Activez la journalisation des actions sur la passerelle (logs d’accès et de modification de configuration).

Surveillance et détection

Même après mise à jour, il est prudent de vérifier si la faille a été exploitée avant l’application du correctif. GitLab n’a fourni aucun indicateur de compromission (IOC). Les pistes suivantes peuvent être explorées :

  • Consultez les logs de l’AI Gateway pour détecter des configurations de flux inhabituelles ou des erreurs de template.
  • Vérifiez l’intégrité des clés JWT stockées (comparaison avec des sauvegardes antérieures).
  • Si vous utilisez un SIEM, créez une règle de corrélation basée sur les tentatives d’exécution de commandes à partir de la passerelle (connexions sortantes vers des hôtes inconnus).

Contexte : une tendance des vulnérabilités d’IA

Ce correctif intervient quelques mois après la correction d’une autre faille similaire, CVE-2026-1868, également notée 9.9, affectant le même composant. Toutes deux relèvent de la classe CWE-1336 (injection de template). L’essor des fonctionnalités d’IA dans les plateformes DevOps multiplie les surfaces d’attaque : selon un rapport de Synk (2025), les vulnérabilités liées aux composants IA ont augmenté de 40 % en un an.

« Les templates de prompts sont devenus un vecteur d’attaque prisé car ils permettent d’exécuter du code dans un contexte souvent privilégié. Les équipes de sécurité DevOps doivent intégrer cette menace dans leur modélisation des risques. » - Analyse de l’ANSSI, septembre 2026.

L’ANSSI recommande de suivre les avis de sécurité des éditeurs et d’automatiser les mises à jour des composants critiques comme l’AI Gateway, au même titre que les serveurs d’application.

Conclusion : agir sans délai

La faille critique GitLab AI Gateway (CVE-2026-90970, CVSS 9.9) expose les organisations auto-hébergeant leur passerelle à un risque d’exécution de commande arbitraire. Même si aucune exploitation active n’est connue à ce jour, la gravité de la vulnérabilité et l’absence de contournement imposent une mise à jour immédiate vers les versions 19.2.4, 19.3.2 ou 19.4.1 selon votre ligne de version.

Pour résumer les actions à mener :

  1. Identifiez la version de votre AI Gateway (docker inspect ou helm list).
  2. Vérifiez si elle est dans la plage affectée (≥18.1.6 et <19.2.4 / 19.3.<19.3.2 / 19.4.<19.4.1).
  3. Mettez à jour vers la version corrigée correspondante en suivant la procédure Docker ou Helm ci-dessus.
  4. Après mise à jour, surveillez les logs pour détecter d’éventuelles traces d’exploitation antérieure.
  5. Intégrez la veille sur les vulnérabilités des composants IA dans votre processus DevOps.

N’attendez pas : un correctif existe, et la fenêtre d’exploitation pourrait se refermer après la publication de preuves de concept. Protégez dès maintenant vos serveurs auto-hébergés et vos données sensibles.