GitLab a corrigé une vulnérabilité critique dans son Self-Hosted AI Gateway. Dans certaines conditions, un utilisateur authentifié disposant d’un accès à Duo Agent Platform pouvait fournir une configuration de flow spécialement construite, sortir du sandbox des templates de prompts et exécuter des commandes sur le serveur AI Gateway. La faille CVE-2026-90970 est notée 9,9 en CVSS 3.1.
Que s’est-il passé ?
GitLab AI Gateway est un service autonome utilisé par les fonctions d’IA natives de GitLab Duo. Pour certains workflows, des données servent à construire dynamiquement des prompts et des flows.
Le problème corrigé concernait la neutralisation insuffisante d’éléments spéciaux dans un template de prompt de custom flow. Une configuration spécialement construite pouvait permettre à un utilisateur déjà authentifié et autorisé à utiliser Duo Agent Platform de franchir le sandbox du template.
La conséquence possible n’était pas simplement de modifier le comportement du modèle : elle pouvait aller jusqu’à l’exécution arbitraire de commandes sur l’AI Gateway.
La frontière franchie
On passe de « l’utilisateur influence un workflow IA » à « l’utilisateur peut potentiellement exécuter des commandes sur l’infrastructure qui héberge ce workflow ».
Le sandbox du prompt n’est qu’une couche
Lorsqu’on sécurise un agent IA, on pense souvent aux fichiers, au réseau, aux outils ou aux credentials auxquels le modèle peut accéder. Ces protections restent indispensables.
Mais un agent moderne repose sur une chaîne plus longue :
Entrée utilisateur → configuration du workflow → moteur de templates → prompt → modèle → outils → système d’exploitation
Une faiblesse dans une couche placée en amont peut court-circuiter celles qui viennent après.
Le moteur de templates devient une surface d’attaque
Les templates permettent de construire dynamiquement des instructions et des workflows. Mais ils doivent être considérés comme du code qui transforme potentiellement des données contrôlées par un utilisateur.
La règle reste la même que dans les applications classiques : une donnée non fiable ne doit jamais devenir une instruction interprétable sans séparation stricte entre données et logique.
Injection SQL, injection de commandes, Server-Side Template Injection ou XSS reposent déjà sur ce principe. Les agents IA ne font pas disparaître ces problèmes : ils ajoutent simplement de nouvelles couches où ils peuvent apparaître.
Prompt injection et sandbox escape ne sont pas la même chose
Une prompt injection cherche généralement à influencer le comportement du modèle : ignorer une instruction, utiliser un outil ou révéler une information.
Un sandbox escape franchit une frontière technique censée empêcher l’accès à un environnement plus privilégié.
CVE-2026-90970 appartient davantage à cette seconde catégorie : le risque porte sur le système qui héberge l’agent, pas uniquement sur la réponse du modèle.
Pourquoi un AI Gateway est sensible
Une AI Gateway peut occuper une position centrale entre les utilisateurs, les modèles et les capacités d’action. Selon l’architecture, elle peut interagir avec des workflows, des dépôts, des services internes, des credentials ou des endpoints de modèles.
Plus ce composant dispose de possibilités d’action, plus sa compromission peut devenir structurante.
C’est le même principe que pour une console d’administration : la criticité dépend autant du rôle du composant que de la vulnérabilité elle-même.
Quels systèmes GitLab sont concernés ?
La vulnérabilité concerne les installations GitLab Self-Hosted AI Gateway.
- versions depuis 18.1.6 et avant 19.2.4 ;
- branche 19.3 avant 19.3.2 ;
- branche 19.4 avant 19.4.1.
GitLab recommande de mettre à jour immédiatement vers 19.2.4, 19.3.2 ou 19.4.1, selon la branche utilisée.
GitLab indique avoir déjà déployé le correctif sur les AI Gateways qu’il héberge. Les utilisateurs de GitLab.com, GitLab Dedicated et des instances Self-Managed utilisant un AI Gateway hébergé par GitLab n’ont donc pas d’action spécifique pour cette vulnérabilité.
Une défense en profondeur indispensable
Un sandbox reste utile, mais il ne devrait jamais être l’unique frontière.
1. Isoler réellement l’exécution
Les commandes et outils de l’agent devraient s’exécuter dans un environnement limité : conteneur, VM ou environnement éphémère, avec le moins de privilèges possible.
2. Appliquer le moindre privilège
Un agent ne devrait recevoir que les accès nécessaires à sa tâche : fichiers, réseaux, secrets et API doivent être bornés.
3. Considérer flows et templates comme non fiables
Les prompts, définitions de flows et templates provenant d’un utilisateur doivent être traités comme des entrées potentiellement hostiles.
4. Séparer orchestration et raisonnement
Le modèle peut participer au raisonnement, mais les opérations sensibles peuvent rester encadrées par des workflows déterministes contrôlés par l’application.
5. Journaliser les actions
Il faut pouvoir déterminer quel agent a exécuté une action, avec quelles permissions, depuis quelle requête et avec quel résultat.
Ce que cela suggère pour TechAtelier
Ce type de vulnérabilité donne une piste utile pour qualifier les services IA dans une analyse de posture.
Au lieu d’identifier seulement « un service IA est présent », il peut être pertinent de demander :
- dispose-t-il de capacités d’exécution ?
- peut-il accéder au réseau interne ?
- manipule-t-il des secrets ?
- utilise-t-il des templates dynamiques ?
- fonctionne-t-il avec des privilèges élevés ?
- est-il isolé du système hôte ?
Cela permet de différencier un simple endpoint d’inférence d’un véritable agent disposant de capacités système.
L’IA ne remplace pas les règles classiques de sécurité
Les agents introduisent de nouvelles attaques, comme la prompt injection. Mais beaucoup de vulnérabilités graves restent liées à des problèmes connus : mauvaise isolation, injection, privilèges excessifs, données non fiables interprétées comme du code ou secrets trop accessibles.
L’IA ne rend pas ces principes obsolètes. Elle les rend encore plus importants.
Ce qu’il faut retenir
CVE-2026-90970 montre qu’un sandbox situé au niveau du prompt ne constitue pas à lui seul une frontière suffisante.
Un agent IA moderne est une chaîne de composants : configuration → templates → modèle → outils → système. Chacune de ces étapes doit être considérée comme une frontière de sécurité potentielle.
La bonne question n’est donc plus seulement : « le modèle peut-il être manipulé ? », mais aussi : « que se passe-t-il si l’une des couches autour du modèle est compromise ? »
Sources
Publié le 3 octobre 2026. Les versions et recommandations correspondent aux publications GitLab disponibles à cette date.