La passerelle IA de GitLab a permis à une configuration de flux astucieusement conçue de s’échapper de son bac à sable de prompts

Le 2 octobre 2026, GitLab a publié une version corrective critique pour son AI Gateway — le middleware qui achemine les requêtes entre une instance GitLab et les modèles de langage que ses fonctionnalités Duo appellent — en désignant CVE-2026-90970 et en lui attribuant une note de 9,9 sur 10. La faille, selon les propres termes de GitLab, aurait pu permettre à « un utilisateur authentifié disposant d'un accès à Duo Agent Platform de s'échapper du bac à sable des modèles d'invite au moyen d'une configuration de flux spécialement conçue, entraînant l'exécution arbitraire de commandes sur l'AI Gateway ». Seules les organisations exploitant un AI Gateway auto-hébergé devaient agir : GitLab avait déjà corrigé les passerelles qu'il exploite pour GitLab.com, GitLab Dedicated et les clients auto-gérés qui utilisent une passerelle hébergée par GitLab, et l'avait indiqué dans l'avis. L'avis de GitLab ne dit pas que la faille ait jamais été exploitée, et l'évaluation jointe au dossier CVE par la Cybersecurity and Infrastructure Security Agency américaine le même jour classe l'exploitation comme « aucune ». La découverte a été attribuée au chercheur HackerOne connu sous le nom d'invisiblemeerkat. L'avis de GitLab, l'enregistrement NVD et la couverture qui a suivi concordent entre eux sur la nature de la faille et sur les versions concernées ; ils concordent tout autant sur ce qui n'est pas connu, à savoir si quelqu'un l'a un jour utilisée. Cette fiche figure aux côtés des autres vulnérabilités documentées de l'infrastructure d'agents dans l'archive des incidents d'IA, où chaque entrée comporte ses propres sources, sa gravité, son niveau de confiance et son indicateur de contestation.

Ce que l’avis dit réellement, et ce qu’il omet

L’avis est court. Publié sur le site de documentation de GitLab sous le titre « GitLab AI Gateway Critical Patch Release: 19.2.4, 19.3.2 et 19.4.1 », il recense une seule correction de sécurité, intitulée « Improper Neutralization issue in custom flow prompt template impacts AI Gateway » et marquée Critique. Il donne le vecteur CVSS 3.1 comme AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H — accessible par le réseau, faible complexité d’attaque, faibles privilèges requis, aucune interaction utilisateur, portée modifiée et impact élevé sur la confidentialité, l’intégrité et la disponibilité. Ce vecteur mérite d’être lu, car il est précis sur l’attaquant : des privilèges faibles, mais des privilèges quand même. L’avis indique « un utilisateur authentifié ayant accès à Duo Agent Platform » et s’arrête là. Il ne précise ni le rôle, ni la permission, ni les conditions auxquelles renvoie sa propre expression « dans certaines conditions ».

Il ne publie pas de preuve de concept, ne décrit pas la configuration de flux forgée et ne propose pas de contournement pour les passerelles qui ne peuvent pas être mises à jour immédiatement. The Hacker News, dans son rapport du 2 octobre, relève les mêmes absences et en ajoute une qui compte sur le plan opérationnel : l’avis ne donne aucun moyen de vérifier si une passerelle a été attaquée avant d’être corrigée. Security Affairs, écrivant le lendemain, consigne les mêmes lacunes.

L'entrée d'énumération des faiblesses communes associée à la CVE est CWE-1336, la neutralisation incorrecte d'éléments spéciaux utilisés dans un moteur de gabarits. L'avis de GitLab n'utilise jamais le mot Jinja. La documentation du dépôt de l'AI Gateway elle-même le fait : son document sur le registre des prompts décrit des fichiers de configuration de prompts qui « prennent en charge l'expression Jinja pour plusieurs rôles tels que user et system », et décrit une classe Prompt qui « utilise Jinja pour interpoler les gabarits de prompt avec les arguments d'entrée ». La faille décrite par la CVE est celle pour laquelle cette catégorie de moteur est célèbre — du texte fourni par l'utilisateur atteignant un gabarit qui est évalué plutôt qu'affiché.

Pourquoi une commande sur cet hôte précis vaut 9,9

L'AI Gateway n'est pas un sidecar. D'après la documentation auto-hébergée de GitLab, il reçoit les requêtes de GitLab, assemble les prompts et communique avec le backend du modèle — un serveur vLLM, Amazon Bedrock, Azure OpenAI ou un fournisseur externe — et, dans un déploiement entièrement auto-hébergé, c'est le composant qui garde les prompts et les réponses à l'intérieur du réseau propre de l'organisation. Le guide d'installation de l'AI Gateway de GitLab indique également aux administrateurs de générer une paire de clés de signature et de transmettre les deux moitiés au service sous forme de variables d'environnement, en tant que AIGW_SELF_SIGNED_JWT__SIGNING_KEY et AIGW_SELF_SIGNED_JWT__VALIDATION_KEY (avec les équivalents pour Duo Workflow). Security Affairs rend la conséquence explicite : l'exécution de commandes sur la passerelle place un attaquant sur un hôte qui détient le matériel de signature JWT et se trouve sur le chemin entre l'instance GitLab et l'infrastructure du modèle.

C’est la différence entre une évasion de bac à sable dans un système jouet et une évasion en production. L’évasion n’a pas besoin d’atteindre un modèle ; elle doit atteindre le processus qui détient les clés avec lesquelles les appels au modèle sont signés.

La documentation produit de GitLab, indépendamment de l’avis, indique que la création ou la modification d’un flux personnalisé nécessite le rôle Maintainer ou Owner dans le projet de gestion, et que son exécution nécessite le rôle Developer ou supérieur. L’avis ne confirme pas cette correspondance, et The Hacker News note qu’aucun rôle n’est nommé au-delà de « Duo Agent Platform access ». Un lecteur qui évalue sa propre exposition doit considérer la documentation comme le modèle d’autorisation du produit et le silence de l’avis comme exactement cela : un silence, et non une contradiction.

Établi, et non établi

Les champs propres au dossier concordent avec tout ce qui précède et n’ajoutent rien qui ne figure dans l’avis. Ce qui suit est la ventilation qu’un lecteur ne peut pas obtenir d’un résumé en une seule ligne.

• Établi : une faille de gravité critique dans GitLab AI Gateway, divulguée le 2 octobre 2026, CVSS 9.9, CWE-1336, accessible par un utilisateur authentifié de Duo Agent Platform via une configuration de flux spécifiquement conçue, entraînant l'exécution de commandes sur l'hôte de la passerelle.

• Établi : la plage concernée — toutes les versions d'AI Gateway de 18.1.6 antérieures à 19.2.4, de 19.3 antérieures à 19.3.2 et de 19.4 antérieures à 19.4.1 — ainsi que les versions corrigées, 19.2.4, 19.3.2 et 19.4.1.

• Établi :Les passerelles hébergées par GitLab ont été corrigées avant publication et leurs clients n’ont aucune mesure à prendre ; les opérateurs auto-hébergés ont été contactés directement avant la publication de l’article, ce que GitLab indique dans l’avis lui-même.

• Établi : le crédit au rapporteur, à invisiblemeerkat, et l'absence de toute déclaration d'exploitation dans la nature.

• Non établi :si quelqu'un l'a exploité. Une évaluation CISA SSVC datée du 2 octobre 2026 et visible dans l'enregistrement NVD indique une exploitation comme « none », une automatisation comme « no » et un impact technique comme « total » ; le catalogue CISA Known Exploited Vulnerabilities ne listait pas CVE-2026-90970 dans sa révision du 20 octobre 2026, que j'ai vérifiée directement. Le modèle EPSS de FIRST a estimé la probabilité d'exploitation au cours des 30 prochains jours à 0,94 pour cent le 21 octobre 2026 — faible, et non nulle.

• Non établi : combien de passerelles auto-hébergées existent, combien étaient exposées, ou si certaines ont été attaquées avant l’application du correctif. Aucune source dans ce dossier ne donne de décompte, et l’avis de GitLab ne fournit aucune méthode de détection.

La plage affectée, ainsi que les versions pour lesquelles aucun correctif n’est indiqué

L’arithmétique des versions est moins nette que ne le suggèrent les trois versions corrigées. La plage concernée commence à 18.1.6, et aucune version corrigée n’est publiée sur une branche inférieure à 19.2.4. Toute passerelle de 18.1.6 à la série 19.1 se situe donc dans la plage concernée indiquée, sans version corrigée nommée pour elle. The Hacker News signale la même conséquence et les questions qui s’ensuivent : la documentation d’installation de GitLab demande aux administrateurs d’exécuter l’image de passerelle dont la version correspond à leur version mineure de GitLab, et l’avis ne précise pas si une passerelle 19.2.4 fonctionne avec GitLab 19.1 ou antérieur, ni si des correctifs pour les branches plus anciennes sont prévus. La politique de versions prises en charge de GitLab, comme le note The Hacker News, répertorie actuellement 19.4, 19.3 et 19.2 — les trois mêmes branches qui ont reçu des correctifs.

La remédiation consiste à remplacer le conteneur plutôt qu’à appliquer un correctif : la passerelle est fournie sous la forme de sa propre image Docker ou de son propre chart Helm. Le guide d’installation de GitLab décrit l’arrêt et la suppression du conteneur en cours d’exécution, la récupération de la nouvelle image avec un tag self-hosted-vX.Y.Z-ee, puis son redémarrage avec les variables d’environnement intactes ; les déploiements Helm définissent le tag dans le champ image du chart. Ni l’avis ni le guide d’installation ne fournit de signature ou d’indicateur permettant de distinguer une passerelle attaquée d’une passerelle saine.

La même classe de bug, huit mois plus tôt

Ce n'est pas la première fois que GitLab publie un score de 9,9 pour une injection de modèle dans l'AI Gateway. Le 6 février 2026, GitLab a publié les versions 18.6.2, 18.7.1 et 18.8.1 de l'AI Gateway pour CVE-2026-1868, décrite dans cet avis comme un « problème d'expansion de modèle non sécurisée » dans lequel le composant Duo Workflow Service était « vulnérable à une expansion non sécurisée de modèle de données fournies par l'utilisateur via des définitions de flux Duo Agent Platform spécialement conçues », exploitable pour un déni de service ou une exécution de code sur la passerelle. Le vecteur CVSS est identique à celui d'octobre, caractère pour caractère, et le CWE aussi. Le rapporteur était différent : celui-ci a été découvert en interne, par le membre de l'équipe GitLab Joern Schneeweisz.

L'avis d'octobre ne mentionne pas celui de février, et The Hacker News le dit explicitement. La question de savoir si les deux partagent une cause racine, un correctif qui n'a pas tenu, ou simplement un langage et un modèle de menace reste sans réponse dans l'un comme dans l'autre des documents publics. Ce qui est établi, c'est qu'un moteur de templates dans un composant d'intergiciel IA a désormais produit deux avis critiques d'exécution de commandes avec le même score la même année, et que le second a nécessité qu'un chercheur externe le découvre.

Qu’est-ce qui a changé, et quelles décisions restent aux opérateurs ?

Le changement concret tient à trois étiquettes d'image et à une campagne de prise de contact directe. GitLab affirme avoir contacté les clients disposant d'une passerelle auto-hébergée avant la publication, et l'avis a été publié le même jour que les images corrigées. Pour tous les autres — GitLab.com, GitLab Dedicated et les instances auto-gérées pointant vers une passerelle hébergée par GitLab — le correctif avait déjà été appliqué côté serveur et, selon GitLab, aucune action n'était nécessaire.

Pour un opérateur auto-hébergé, la décision est plus étroite et moins confortable qu’un cycle de correctifs normal. Il n’existe aucune solution de contournement pour une passerelle qui ne peut pas être déplacée immédiatement. Il n’existe aucune méthode publiée permettant d’établir si l’hôte a été compromis au préalable, ce qui signifie que la seule option rétrospective est la plus ordinaire : considérer le conteneur comme un système dont l’intégrité n’est pas prouvée, et rechercher des signes d’exécution hors de son comportement normal. Et pour les passerelles sous 18.x ou 19.1, l’avis ne nomme aucune version cible — une omission que The Hacker News rapporte et que l’avis de GitLab ne traite pas.

La classification de l’archive elle-même est délibérément plus étroite que celle du fournisseur. Elle consigne cette entrée comme une vulnérabilité, avec un degré de confiance A, des sources concordantes et non contestées, aucun préjudice réel enregistré, et un champ de gravité « élevé » face au « critique » de GitLab et de NVD. Ce sont là des réponses à des questions différentes : le score décrit ce que la faille permettrait, et la note de l’archive décrit ce qui est connu comme s’étant produit. Au vu des informations publiques, rien ne s’est produit — aucune exploitation, aucune victime, aucun rapport d’incident. L’intérêt de l’entrée est qu’elle documente, avec un numéro CVE et une version corrigée, exactement comment un modèle de prompt est devenu une ligne de commande dans le middleware dont dépendent les fonctionnalités d’IA d’entreprise.