La faille GitLab AI Gateway corrigée par l’éditeur est notée CVSS 9.9 et ne concerne que les éditions auto-hébergées : un utilisateur faiblement privilégié peut sortir du bac à sable de l’agent Duo et faire exécuter des commandes au serveur. Si vous hébergez GitLab dans votre SI et que les fonctions Duo sont actives, la mise à jour est la seule réponse sérieuse — il n’existe pas de contournement durable.
Ce que fait réellement la faille GitLab AI Gateway
AI Gateway est le composant qui relie votre instance GitLab aux modèles de langage utilisés par Duo : complétion de code, explication de diff, agents de refactoring. Pour fonctionner, il reçoit du texte fourni par l’utilisateur et le transforme en appels outillés exécutés côté serveur. C’est exactement ce chaînage qui a été détourné.
La vulnérabilité, suivie sous la référence CVE-2026-90970, permet à un compte disposant du simple accès à l’agent Duo de franchir l’isolation prévue autour de l’exécution et d’obtenir une exécution de code à distance sur l’hôte qui porte AI Gateway. Il ne s’agit donc pas d’un abus de quota ou d’une fuite de prompt : le périmètre atteint est la machine elle-même, avec les droits du service.
Le score de 9,9 traduit cette combinaison : prérequis d’accès très bas, impact maximal. Dans une instance GitLab, un « utilisateur faiblement privilégié » inclut un développeur externe sur un projet, un prestataire invité, ou n’importe quel compte dont le mot de passe a déjà fuité ailleurs.
Pourquoi une PME auto-hébergée est en première ligne
La version SaaS gitlab.com est administrée par l’éditeur et corrigée sans action de votre part. Le risque se concentre sur les installations self-managed, très répandues dans les PME et ETI françaises qui veulent garder leur code source sur leur propre infrastructure, parfois pour des raisons contractuelles ou réglementaires.
Or ces instances cumulent souvent trois facteurs aggravants. Elles sont patchées au rythme des fenêtres de maintenance, pas au rythme des publications de sécurité. Elles tournent fréquemment sur un serveur qui héberge aussi les runners CI, donc les secrets de déploiement. Et les fonctions Duo ont pu être activées pendant une phase d’essai, puis oubliées en production sans que personne ne considère AI Gateway comme un service exposé.
Un serveur GitLab compromis n’est pas un serveur applicatif de plus : c’est le point où se croisent votre code, vos jetons d’intégration continue et souvent vos clés d’accès cloud. C’est pour cette raison qu’une faille d’exécution de code y mérite un traitement de type incident, et pas une simple ligne de backlog.
Comment savoir si vous êtes exposé
Trois vérifications suffisent à trancher. D’abord la nature de l’instance : si vos développeurs se connectent à une adresse en gitlab.votre-domaine.fr, vous êtes en self-managed. Ensuite la version installée, lisible dans l’interface d’administration ou via gitlab-rake gitlab:env:info ; comparez-la aux versions correctives publiées par GitLab. Enfin l’état de Duo : si les fonctions d’IA sont désactivées au niveau de l’instance, la surface d’attaque n’est pas la même, mais la mise à jour reste à planifier.
Côté détection, concentrez la recherche sur le processus AI Gateway : création de processus enfants inhabituels, connexions sortantes vers des destinations non prévues, écriture de fichiers dans les répertoires du service. Une anomalie dans ces trois axes, sur une instance non corrigée, justifie une analyse approfondie plutôt qu’un simple redémarrage.
Que faire maintenant
- Identifiez vos instances GitLab self-managed, y compris celles montées par une équipe projet en dehors du périmètre officiel de la DSI.
- Appliquez la version corrective publiée par GitLab sur chaque instance concernée, en commençant par celles accessibles depuis Internet.
- Désactivez les fonctions Duo et AI Gateway au niveau de l’instance si la mise à jour ne peut pas être faite dans la journée, le temps d’ouvrir une fenêtre de maintenance.
- Restreignez l’accès réseau à AI Gateway aux seules adresses internes qui en ont besoin, et retirez l’exposition publique si elle n’est pas justifiée.
- Relisez les journaux du service et faites tourner les jetons CI et les clés cloud portés par le serveur si vous constatez la moindre anomalie.
Vos agents IA, vos copilotes de code ou vos intégrations LLM sont exposés à ce type d’évasion de bac à sable ? AIGIL sécurise les agents IA et le code généré par LLM, en production comme dans vos chaînes d’intégration continue.
Ce schéma n’est pas isolé : nous avions documenté le même type de dérive sur un serveur MCP Grafana vulnérable au SSRF, et plus largement sur les injections de prompt contre les assistants IA branchés sur Jira et Confluence. À chaque fois, la cause est la même : un composant d’IA qui traite de l’entrée utilisateur avec les droits d’un service interne.
Ce qu’il faut retenir
- La faille CVE-2026-90970 touche AI Gateway sur les instances GitLab auto-hébergées, avec un score CVSS de 9,9.
- Un compte faiblement privilégié suffit à s’échapper du bac à sable de l’agent Duo et à exécuter du code sur le serveur.
- Les instances gitlab.com en SaaS sont corrigées par l’éditeur ; le risque est entièrement côté self-managed.
- Aucun contournement durable n’est proposé : la mise à jour est la mesure principale, la désactivation de Duo n’est qu’un palliatif.
- Un serveur GitLab compromis expose aussi vos jetons CI et vos clés de déploiement, donc le périmètre à surveiller dépasse le dépôt de code.