GitLab corrige CVE-2026-90970 critique à AI Gateway; correctifs pour auto-hôte

GitLab a publié un avis de sécurité qui décrit la vulnérabilité critique dans son service AI Gateway qui, sous certaines conditions, a permis à un utilisateur authentifié ayant accès à la plate-forme Duo Agent de s'échapper de la "sandbox" de modèles rapides et d'exécuter des commandes arbitraires dans la passerelle elle-même. Le jugement a été enregistré comme CVE-2026-90970, a reçu un score CVSS de 9,9 / 10 et GitLab a publié la correction le 2 octobre. Les versions contenant la solution sont 19.2.4, 19.3.2 et 19.4.1 du composant de la passerelle d'IA.

Faits confirmés : GitLab décrit le problème comme une faiblesse dans le modèle rapide d'un « flux personnalisé » - flux personnalisés créés dans la plate-forme de Duo Agent pour automatiser les tâches - qui pourrait permettre l'"évasion" de l'environnement sûr et aboutir à l'exécution de commandes dans la machine qui exécute la passerelle. GitLab exploite des passerelles administrées pour ses clients sur GitLab.com et GitLab Dédiée et prétend avoir déjà atténué le problème dans ses passerelles gérées; Seules les organisations qui hébergent leur propre passerelle d'IA (auto-accueil) devraient appliquer le patch. L'avis identifie les versions fixes ci-dessus et ne énumère aucune autre mesure d'atténuation ou un formulaire incorporé pour vérifier si une passerelle a été attaquée avant de la mettre à jour.

Contexte et portée techniques: La passerelle AI est le composant qui relie une instance GitLab à des modèles IA externes et, dans les déploiements auto-organisés, est installée sous forme d'image Docker ou par Helm. Cette passerelle stocke les clés de signature pour JSON Web Tokens (JWT) et maintient des connexions avec les fournisseurs internes de GitLab et de modèles - par conséquent, l'implication potentielle n'est pas seulement vers le conteneur de passerelle, mais aussi vers les identifiants qui facilitent l'authentification et l'autorisation dans l'environnement. GitLab qualifie le problème de la même nature qu'une vulnérabilité précédente en février (CVE-2026-1868) - tous deux liés à des faiblesses dans le moteur modèle, classe CWE-1336 -, qui indique un modèle dans la façon dont les modèles de flux peuvent être manipulés pour briser les limites d'exécution.

Ce que nous savons et ce qui ne l'est pas : a confirmé qu'un utilisateur authentifié ayant accès à Duo Agent Platform était la route d'attaque décrite ; cependant, l'avis ne détaille pas les exigences exactes (par exemple, quel rôle spécifique de l'utilisateur était nécessaire ou quelles conditions de la configuration de passerelle ont été exploitées). Un test de concept public n'a pas non plus été publié, et l'entrée de la CVE comprend une évaluation de la CISA qui énumère l'exploitation comme « nulle » dans son domaine d'exploitation connu, ce qui laisse entendre qu'il n'y a pas de confirmation publique des attaques dans le tableau général. Malgré cela, la nature de la vulnérabilité - l'exécution de commandes dans un composant qui garde des clés sensibles - rend le risque grave et avec des conséquences potentiellement graves si exploité dans des environnements productifs.

Conséquences réelles et risque pour les organisations: si un attaquant parvient à exécuter du code dans une passerelle engagée, il peut essayer d'exfilter ou de faire pivoter les touches JWT, intercepter ou modifier les requêtes et réponses IA, se déplacer latéralement vers les fournisseurs d'instance ou de modèle GitLab, et même déployer des charges malveillantes. Dans les environnements où la politique du client exige que les données d'entrée et de sortie de l'IA restent dans le périmètre (porte d'accès autoportée), l'exposition à la passerelle compromettrait la garantie et les données sensibles aux risques. Comme il s'agit d'un élément qui a souvent un réseau étendu permet de communiquer avec GitLab et les API externes, l'escalade de l'impact est plausible.

Recommandations spécifiques et immédiates (vérifiables et exécutoires): 1) Mise à jour immédiate n'importe quelle passerelle d'IA auto-installée à l'une des versions corrigées: 19.2.4, 19.3.2 ou 19.4.1 selon le cas pour la ligne utilisant votre installation. Pour déployer Docker, arrêtez et retirez le conteneur actuel, faites tirer Docker de la nouvelle étiquette et exécutez le conteneur avec la même configuration; GitLab utilise des étiquettes de nom telles que auto-hosted-v19.4.1-e. Pour déployer avec Helm, ajustez l'image dans le graphique (image.tag) et appliquez la mise à jour pour afficher la nouvelle étiquette. 2) Rotation des clés sensibles et des références: si la passerelle enregistre les clés JWT ou les identifiants de fournisseur de modèle, préparez un plan de rotation immédiat pour ces clés après mise à jour. Bien qu'il n'y ait pas de confirmation de fonctionnement, la rotation réduit le risque d'engagement préalable. 3) Examiner et restreindre l'accès: audit qui a permis à Duo Agent Platform et applique le principe de privilège mineur ; envisager de désactiver la création de flux par des utilisateurs non essentiels jusqu'à ce que la mise à jour soit terminée. 4) Suivi et identification des indicateurs: review gateway et host logs pour détecter des exécutions anormales, des processus inconnus, des réinitiations soudaines ou des changements dans les paramètres de flux ; si vous avez des instantanés ou des sauvegardes, comparez-les pour détecter des modifications. 5) Environnement d ' essai: d'abord appliquer le patch dans les environnements de mise en scène et de validation à votre version GitLab avant de déployer en production, car le guide d'installation recommande d'utiliser l'image de passerelle correspondant à la version GitLab inférieure et l'avis ne précise pas la compatibilité inverse entre les versions.

Mesures d'atténuation lorsqu'il n'est pas possible de mettre à jour immédiatement: si les restrictions opérationnelles ne peuvent pas appliquer le patch immédiatement, réduire le risque - temporairement - en isolant le réseau de passerelle pour limiter sa capacité de communiquer en dehors du périmètre, appliquer des contrôles pare-feu pour restreindre l'accès entrant et sortant, et désactiver la fonctionnalité de flux ou la capacité de l'utilisateur de charger les configurations de flux jusqu'à ce que la mise à jour soit possible. Ces mesures sont palliatives et ne remplacent pas la mise à jour du logiciel.

Que communiquer aux équipes et aux prochaines étapes : informer les équipes de sécurité et d'infrastructure, documenter la version de la passerelle et la date/heure de la mise à jour, garder la connexion avant de faire pivoter les clés et aviser les services de conformité si la passerelle gère les données réglementées. GitLab a remercié le chercheur en reporting (utilisateur "invisiblemeerkat" dans HackerOne) et déjà résolu le problème dans les passerelles qu'il gère pour les clients; cependant, la mise à jour est la responsabilité des opérateurs de passerelle auto-accueillés.

Sources et lecture supplémentaire: L'avis de sécurité et la documentation de sécurité de GitLab sont disponibles sur le site Internet de GitLab ( https: / / about.gitlab.com / sécurité /). L'entrée CVE est disponible dans le NVD pour les détails structurés et les liens associés ( https: / / nvd.nist.gov / vuln / detail / CVE-2026-90970), et pour le contexte technique sur le type de faiblesse mentionné, voir la définition CWE-1336 dans MITRE ( https: / / cwe.mitre.org / data / définitions / 1336.html).

Résumé: si vous hébergez votre propre passerelle AI, mettez à jour maintenant. Si votre GitLab est hébergé par GitLab (GitLab.com, GitLab Dedicated ou utilise une passerelle gérée), GitLab indique que vos passerelles ont déjà été patchées et qu'aucune action n'est nécessaire de votre part. Lorsqu'il n'est pas possible de mettre à jour immédiatement, d'isoler, de restreindre l'accès et de préparer des rotations clés; documenter toutes les mesures et maintenir une surveillance accrue jusqu'à ce que le confinement et la vérification soient terminés.