GitLab a publié la version corrective 19.3.1 le 26 août. Parmi les correctifs figure CVE-2026-18252, décrit comme un « problème d’inclusion de fonctionnalité depuis une sphère de contrôle non fiable » dans l’agent Duo Claude AI, qui affecte GitLab EE. C’est la vulnérabilité d’agent IA la plus instructive révélée cette semaine, et elle va être décrite de manière inexacte.

Ce qui s’est réellement passé

Selon les mots mêmes de GitLab : l’entreprise « a remédié à un problème qui, dans certaines conditions, aurait pu permettre à un utilisateur authentifié disposant de permissions de niveau développeur d’exécuter des commandes arbitraires dans un contexte CI, en raison du traitement par l’agent Claude d’une configuration provenant d’une source contrôlée par l’utilisateur ». L’agent lisait sa configuration à partir d’un emplacement auquel un développeur pouvait écrire. Quelle que soit l’instruction contenue dans cette configuration, il l’exécutait — dans CI, avec les identifiants de CI.

Ce que l’interprétation courante comprend mal

Tout ce qui implique un LLM et l’exécution de commandes est classé comme injection de prompt ou jailbreak — un modèle convaincu de contourner ses garde-fous. Ce n’est ni l’un ni l’autre. Il s’agit d’une erreur classique de frontière de confiance, la même catégorie de bug que la lecture d’un script de build depuis un chemin non fiable, et elle existerait à l’identique si le composant qui lit cette configuration ne contenait aucun modèle du tout. La distinction compte pour la remédiation : l’injection de prompt se limite par des défenses au niveau du modèle, probabilistes et incomplètes, tandis qu’ici la correction consiste à ne pas lire de configuration depuis un emplacement inscriptible. GitLab a corrigé le problème de cette seconde manière, ce qui est la bonne, et le qualifier d’échec de sécurité de l’IA masque le fait que la correction est déterministe.

Qui a attribué la note, et pourquoi c’est notable

La note est de 7.3 High sur le vecteur CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N. GitLab étant sa propre CNA, cette note correspond à l’évaluation de son propre défaut par l’entreprise, publiée alors que le détail technique reste sous embargo. Le vecteur est cohérent en interne — faibles privilèges requis, interaction utilisateur requise, aucun impact sur la disponibilité — et rien ne permet de penser qu’il soit erroné. Mais un analyste indépendant ne peut pas le vérifier avant que GitLab n’ouvre le dossier, en général environ 30 jours après le correctif. D’ici là, la gravité d’une vulnérabilité d’agent dans une plateforme CI largement déployée repose entièrement sur la parole de la plateforme.

Ce qu’il faut faire maintenant

Les versions concernées sont GitLab EE 18.9 avant 19.1.7, 19.2 avant 19.2.5 et 19.3 avant 19.3.1. La faille a été signalée via le programme HackerOne de GitLab. La condition préalable est un compte avec des permissions de niveau développeur, ce qui, dans la plupart des organisations, n’est pas un seuil élevé — c’est le niveau d’autorisation standard pour toute personne qui écrit du code. Les instances auto-gérées exécutant Duo avec l’agent Claude doivent traiter ce correctif comme la priorité de la version.