GitLab AI Gateway : la clé API de votre LLM est lisible par n'importe quel Reporter — CVE-2026-8810
> En bref : Sur GitLab 18.6.0 à 18.8.1 (self-managed et SaaS), la configuration de l'AI Gateway — clé API du provider LLM comprise — était lisible par tout utilisateur au rôle Reporter. Les logs de la gateway exposaient aussi des extraits des prompts d'autres utilisateurs. Corrigé dans 18.8.2. Si vous avez l'AI Gateway activée : faites tourner la clé du provider et vérifiez son historique d'utilisation.
Ce qu'est l'AI Gateway
L'AI Gateway est le composant central des appels LLM introduit dans GitLab 18.6 : un seul endpoint pour toutes les fonctions IA (Copilot, Duo, intégrations custom), avec routage vers les providers (OpenAI, Anthropic, etc.), quotas et suivi d'utilisation.
En contrepartie, elle détient deux choses : la clé API du provider (dépense + accès au compte) et le contenu des prompts (questions posées à l'IA = données métier, parfois du code).
La faille : un Reporter peut lire les deux
/api/v1/ai_gateway/config\\) était lisible avec le rôle Reporter. La réponse contenait la clé API du provider en clair./api/v1/ai_gateway/logs\\) exposait, pour le même rôle, des extraits des prompts d'autres utilisateurs de l'instance.CVSS 6.5 (impact limité au périmètre de l'instance + du compte provider). Ce n'est pas une RCE — mais c'est la classe de faille classique : un secret stocké pour le service, lisible par l'utilisateur le moins privilégié du produit.
Ce que ça expose concrètement
Qui est affecté
Ce qu'il faut vérifier maintenant
La leçon
Une AI Gateway est un nouveau genre de composant : c'est à la fois un vault de secrets (clés provider) et un flux de données (prompts). Les deux méritent le même traitement qu'un API gateway : least privilege sur la config, audit des logs, rotation des clés. Quand vous ajoutez un LLM dans la stack, ajoutez sa gateway à la liste des choses à tester.
Vous éditez un logiciel ? CleanIssue réalise des audits de sécurité pour votre produit en conditions réelles, sans accès au code. Pour une première lecture de votre exposition, commencez par une revue externe de votre application.
Articles liés
Trois analyses proches pour continuer la lecture sur la meme surface de risque.
GitLab CVE-2026-85706 : lecture de fichiers arbitraires sans authentification (CVSS 10), scans dès les premières heures
Un path traversal dans l'API repository commits (CVE-2026-85706, CVSS 10.0) permet à un utilisateur non authentifié de lire des fichiers arbitraires du serveur GitLab — logs et configurations contenant credentials et secrets — dès qu'un projet public existe. Des probes actives observées dès le 11 septembre, KEV CISA avec échéance au 14 septembre. Correctifs : 19.1.8, 19.2.6, 19.3.2, incluant aussi une désérialisation EE (CVE-2026-87719, 9.9).
GitLab et CVE-2023-7028 : pourquoi cette faille de reset de mot de passe a inquiété tout le monde
CVE-2023-7028 permettait un takeover via reset de mot de passe sans interaction utilisateur dans certaines versions de GitLab. Voici pourquoi cette faille a tant marqué.
RCE GitLab via Oj : une chaîne de corruption mémoire cachée dans un patch non-sécurité
Deux bugs de corruption mémoire dans Oj (parser JSON Ruby) permettent à tout utilisateur authentifié de lancer des commandes en tant que `git` sur les GitLab auto-hébergés <18.10.8 / <18.11.5 / <19.0.2, via des notebooks Jupyter forgés. Le correctif a été livré le 10 juin mais listé en bug fixes, pas en sécurité. PoC publié le 24 juillet.
Sources
Services associés
Si ce sujet reflète un risque concret sur votre stack, voici les audits CleanIssue les plus pertinents.
Red Team Agent Express
Savoir rapidement ce qu'un inconnu peut faire faire à votre agent. Rapport en 5 jours.
Red Team sur mesure
Plusieurs agents, des serveurs MCP ou des agents livrés par une agence : sur devis.
Le Shield
Le logiciel qui bloquera les actions non autorisées. En développement, accès anticipé pour les premiers clients.