GitLab corrige une faille critique 9,9 de son AI Gateway auto-hébergé
GitLab a comblé le 2 octobre une vulnérabilité critique (CVE-2026-90970, CVSS 9,9) qui permet à un utilisateur connecté d’exécuter des commandes sur l’AI Gateway, le service qui relie une instance GitLab aux modèles d’IA. Seules les équipes qui hébergent leur propre gateway doivent agir : passez en 19.2.4, 19.3.2 ou 19.4.1 sans attendre.
2 octobre 2026. GitLab publie un correctif pour une vulnérabilité critique de son AI Gateway, le service qui connecte une instance GitLab aux grands modèles de langage. 2 octobre 2026. La faille, suivie sous le numéro CVE-2026-90970, obtient un score CVSS de 9,9 sur 10 — à un dixième du maximum. 2 octobre 2026. La CISA ajoute au dossier une évaluation qui classe l’exploitation à « aucune » : pas d’attaque connue, pas de démonstration publique. Pourquoi c’est important : un utilisateur déjà connecté, doté d’un simple accès Duo Agent Platform, peut exécuter des commandes sur le gateway — la pièce qui se tient entre votre dépôt de code et votre modèle d’IA.
Ce que la faille permet vraiment
La vulnérabilité ne touche pas GitLab lui-même, mais l’AI Gateway, le composant séparé qui achemine les requêtes d’IA entre l’instance et les modèles. Concrètement, un utilisateur connecté disposant d’un accès Duo Agent Platform peut, sous certaines conditions, exécuter des commandes sur le gateway.
Le danger est asymétrique. Le gateway n’est pas un simple proxy : il porte souvent des secrets d’API, des clés vers les fournisseurs de modèles et les informations d’identification du compte de service qui parle au LLM. Exécuter une commande sur cette machine, c’est potentiellement lire ces secrets, pivoter vers le fournisseur de modèles, ou manipuler les réponses renvoyées aux développeurs.
Le score de 9,9 — et non 10 — reflète un prérequis : l’attaquant doit déjà être connecté et détenir l’accès Duo Agent Platform. Il ne s’agit donc pas d’une exécution à distance totalement non authentifiée depuis Internet, mais d’une élévation au sein de la chaîne d’IA. Cette nuance ne réduit pas l’urgence : les organisations qui hébergent leur gateway ont précisément des comptes dotés de ce privilège, et un compte compromis suffit à atteindre la machine qui porte les secrets des modèles.
GitLab n’a pas précisé le vecteur technique complet dans son avis, mais le périmètre est limpide : seules les instances qui hébergent leur propre gateway sont concernées. Les clients de GitLab.com, de GitLab Dedicated et les instances auto-gérées qui utilisent un gateway hébergé par GitLab n’ont rien à faire — l’éditeur les a déjà corrigés.
Qui doit patcher, et comment
Le correctif existe dans trois lignes de version du gateway : 19.2.4, 19.3.2 et 19.4.1. Le tableau de correspondance publié par GitLab est sans ambiguïté :
- Version 18.1.6 ou ultérieure, avant 19.2.4 → passez en 19.2.4.
- Version 19.3, avant 19.3.2 → passez en 19.3.2.
- Version 19.4, avant 19.4.1 → passez en 19.4.1.
La zone affectée est large : toute version du gateway de la 18.1.6 jusqu’à la ligne 19.1 est exposée, et aucune version corrigée n’est publiée sous la 19.2.4. Les trois lignes corrigées (19.4, 19.3, 19.2) correspondent exactement aux versions de GitLab qui reçoivent encore des correctifs de sécurité selon la politique de maintenance de l’éditeur.
Le gateway se déploie comme une image Docker ou un chart Helm autonome, avec son propre cycle de mise à jour — il ne se met pas à jour en même temps que l’instance. Pour un déploiement Docker, il faut arrêter et supprimer le conteneur, puis tirer et relancer le nouveau tag, par exemple self-hosted-v19.4.1-ee. Pour Helm, on change le tag dans la configuration d’image du chart.
# Déploiement Docker : remplacer le conteneur par le tag corrigé
docker stop ai-gateway && docker rm ai-gateway
docker run -d --name ai-gateway \
-e AIGW_AUTH__BYPASS_EXTERNAL=true \
registry.gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/self-hosted-v19.4.1-ee:latestDeux détails alourdissent la décision. D’abord, aucun contournement n’est proposé : une instance qui ne peut pas encore être mise à jour reste exposée. Ensuite, GitLab ne fournit aucun moyen de vérifier si un gateway a été compromis avant le correctif — pas d’indicateur de compromission, pas de journal à consulter en priorité.
Un maillon qui concentre le risque
Cette faille illustre un glissement structurel du métier. Pendant des années, la surface d’attaque d’une forge de code se résumait au dépôt et au runner CI/CD. L’ajout de fonctionnalités d’IA a greffé un nouveau maillon privilégié : un service qui parle aux modèles, détient des secrets et traite du code en clair, souvent déployé à la hâte parce qu’il est perçu comme un simple utilitaire.
Le fait que l’accès Duo Agent Platform — une fonctionnalité orientée agents — suffise à déclencher la faille en dit long. On ne sécurise plus seulement qui peut pousser du code, mais qui peut faire quoi sur la chaîne d’IA qui l’assiste. Une erreur de configuration de rôle, et un compte destiné à des agents de test devient un point d’exécution de commandes sur le gateway.
L’absence d’exploitation publique ne doit pas endormir la vigilance. CISA évalue l’exploitation à « aucune » au 2 octobre, mais une RCE 9,9 non authentifiée côté réseau — ou quasi — sur un composant qui porte des secrets de fournisseurs de modèles est exactement le genre de cible que les groupes de rançon ou d’espionnage intègrent vite à leurs boîtes à outils, une fois le correctif rétro-ingéniéré.
Après le correctif : l’audit que la correction ne fait pas
Monter en 19.2.4, 19.3.2 ou 19.4.1 referme la porte, mais ne dit rien de ce qui a pu passer pendant qu’elle était ouverte. GitLab ne fournit aucun indicateur de compromission, ce qui transfère à l’équipe la charge de vérifier elle-même si le gateway a été touché.
La première étape est l’inventaire des secrets. Un gateway auto-hébergé ne se contente pas de router des requêtes : il détient généralement une clé API vers le fournisseur de modèles, un jeton d’accès vers l’instance GitLab, et parfois un compte de service dédié. Tout secret qui a pu transiter par la machine pendant la fenêtre d’exposition doit être considéré comme compromis, donc pivoté — la rotation n’est pas une précaution, c’est la seule posture défendable quand on ne peut pas prouver l’absence d’intrusion.
La deuxième est l’audit des rôles. La faille se déclenche via l’accès Duo Agent Platform, une fonctionnalité récente souvent accordée à la hâte pour des pilotes d’agents. Reprenez la liste des détenteurs de ce privilège, révoquez ceux qui n’en ont plus besoin, et traitez ce droit comme un privilège fort, au même titre qu’un accès administrateur de runner CI/CD. Un compte de test qui traîne peut suffire à transformer la faille en exécution de commandes.
La troisième est la surveillance. Branchez la journalisation du gateway sur votre SIEM, et alertez sur les exécutions de commandes, les accès aux clés et les sorties réseau inhabituelles. Un composant qui porte des secrets de fournisseurs de modèles mérite la même supervision qu’un gestionnaire de secrets — et trop de déploiements le traitent encore comme un simple utilitaire sans journaux.
Verdict
Si vous hébergez votre propre AI Gateway, traitez ce correctif comme une urgence : montez en 19.2.4, 19.3.2 ou 19.4.1 dès maintenant, en commençant par les environnements où le gateway manipule du code ou des données sensibles. Comme aucun indicateur de compromission n’est fourni, passez le gateway en revue après coup — secrets exposés, comptes de service, clés vers les fournisseurs de modèles — et faites pivoter ce qui a pu fuir. Si vous utilisez un gateway hébergé par GitLab, vous n’avez rien à corriger, mais profitez-en pour auditer qui possède l’accès Duo Agent Platform dans votre organisation : c’est le privilège qui transforme cette faille en exécution de commandes.