Une vulnérabilité de GitLab AI Gateway brise le bac à sable et permet l’exécution de commandes

GitLab a corrigé une vulnérabilité de GitLab AI Gateway notée 9,9 sur 10 après que des chercheurs ont découvert un chemin menant à l’exécution arbitraire de commandes. La faille touche les passerelles auto-hébergées et nécessite un utilisateur authentifié disposant d’un accès à GitLab Duo Agent Platform. Un flux personnalisé spécialement conçu peut s’échapper du bac à sable des modèles de prompts et exécuter des commandes avec les privilèges du processus de la passerelle.

L’incident est plus limité qu’une faille exploitable à distance affectant chaque déploiement GitLab. Les passerelles hébergées par GitLab ont été corrigées par l’entreprise, et les clients utilisant ces services n’ont pas besoin de mettre eux-mêmes à jour la passerelle. Les organisations exploitant un AI Gateway auto-hébergé assument la responsabilité immédiate.

Cette distinction crée la tension centrale. L’auto-hébergement donne à une organisation davantage de contrôle sur le traitement par l’IA, l’infrastructure et les chemins de données. Il transfère également au client les responsabilités de correction, de surveillance et de confinement. Dans ce cas, le composant placé dans l’environnement de confiance est devenu une cible d’exécution de commandes.

La vulnérabilité est suivie sous la référence CVE-2026-90970. GitLab a publié les versions 19.2.4, 19.3.2 et 19.4.1 d’AI Gateway le 2 octobre 2026. L’entreprise a exhorté les opérateurs concernés à effectuer la mise à jour immédiatement, mais son avis public n’identifiait aucune solution de contournement et ne fournissait pas de conseils détaillés pour détecter une compromission.

La vulnérabilité de GitLab AI Gateway nécessite une mise à jour immédiate

Le fait urgent est simple : les passerelles auto-hébergées concernées nécessitent une version corrigée d’AI Gateway, et pas seulement une application GitLab mise à jour.

L’avis de correctif critique de GitLab identifie trois versions corrigées : 19.2.4, 19.3.2 et 19.4.1. Le numéro de version pertinent appartient au composant AI Gateway. Il ne doit pas être confondu avec la version d’une instance GitLab connectée.

La plage affectée commence avec AI Gateway 18.1.6. Elle comprend les versions antérieures à 19.2.4, la version 19.3 antérieure à 19.3.2 et la version 19.4 antérieure à 19.4.1. Les organisations exécutant une branche prise en charge plus ancienne doivent sélectionner la version corrigée appropriée.

La formulation importe également pour les installations sur les lignes 18.x et 19.1. GitLab n’a pas répertorié de version de passerelle corrigée antérieure à 19.2.4 dans son avis d’octobre. Les opérateurs de ces lignes ne doivent pas supposer que rester sur une branche plus ancienne assure une protection.

Un AI Gateway auto-hébergé fonctionne comme un service distinct, généralement via un conteneur ou un déploiement Helm. Mettre à jour l’application GitLab principale ne prouve pas automatiquement que l’image de la passerelle a été remplacée. Les administrateurs doivent inspecter le déploiement de la passerelle lui-même et confirmer le tag de l’image en cours d’exécution.

GitLab a déclaré avoir contacté les clients utilisant des passerelles auto-hébergées avant de publier l’avis. L’entreprise a également indiqué qu’un correctif avait déjà été déployé sur les passerelles hébergées par GitLab. Cela protège GitLab.com, GitLab Dedicated et les instances self-managed connectées à une passerelle hébergée par GitLab.

Cette portée fait de l’identification des actifs le premier défi opérationnel. Une équipe de sécurité peut savoir que son organisation utilise GitLab Duo sans savoir quel modèle de passerelle le prend en charge. Le service peut être exploité par GitLab ou déployé dans l’environnement du client.

Les équipes doivent vérifier cette distinction à l’aide des registres de déploiement, des inventaires de conteneurs, des versions Helm et de la configuration de GitLab Duo. Elles doivent éviter de déduire la propriété de la passerelle à partir du seul nom du produit GitLab. Une instance GitLab self-managed peut toujours utiliser une passerelle hébergée par GitLab.

L’enregistrement CVE attribue à la vulnérabilité les impacts maximums sur la confidentialité, l’intégrité et la disponibilité dans son vecteur CVSS 3.1. Le score est de 9,9 plutôt que de 10, car l’exploitation requiert de faibles privilèges. Elle ne requiert aucune interaction utilisateur et le service vulnérable est accessible sur un réseau.

De faibles privilèges ne signifient pas un accès anonyme. GitLab indique qu’un attaquant doit être authentifié et avoir accès à Duo Agent Platform. Cette exigence réduit la population initiale d’attaquants, mais elle inclut les comptes compromis et potentiellement des initiés malveillants.

La faille franchit ensuite une frontière de sécurité après cet accès initial. Un utilisateur autorisé à travailler avec des flux d’IA ne devrait pas hériter de l’autorisation d’exécuter des commandes du système d’exploitation sur la passerelle. La vulnérabilité transforme un accès au niveau de l’application en contrôle d’un environnement d’exécution plus sensible.

Les opérateurs doivent traiter la mise à jour comme un changement indépendant nécessitant des preuves indépendantes. Un ticket de changement GitLab clôturé n’établit pas que l’AI Gateway est sûr. La preuve correcte est la version de passerelle en cours d’exécution et un déploiement vérifié sur chaque réplique.

Cette vérification doit inclure les environnements de développement, de préproduction, de reprise après sinistre et temporairement réduits. Les instances de passerelle oubliées restent importantes si elles conservent une connectivité réseau ou des identifiants. Une interface inactive ne garantit pas qu’un service est inaccessible.

Un flux personnalisé a transformé des données de modèle en comportement exécutable

La défaillance principale n’est pas qu’un modèle d’IA a écrit une commande dangereuse. C’est qu’une frontière de modèle a permis à des données conçues de manière malveillante d’atteindre un comportement exécutable de l’application.

GitLab décrit le problème comme une neutralisation incorrecte dans un modèle de prompt de flux personnalisé. Un flux personnalisé est un workflow d’IA configurable et en plusieurs étapes au sein de Duo Agent Platform. Il peut combiner des prompts, des composants, des décisions de routage et des outils dans une définition YAML.

La documentation sur les flux personnalisés de l’entreprise montre pourquoi ces définitions sont davantage que du simple texte de prompt. Les flux peuvent être créés, testés, publiés, activés pour des projets et déclenchés via l’activité GitLab. Ils fonctionnent comme une configuration applicative autour d’un agent.

Le chemin vulnérable impliquait un bac à sable de modèle de prompt. Un bac à sable est un environnement d’exécution restreint conçu pour empêcher un modèle d’accéder à des attributs ou des fonctions non sûrs. CVE-2026-90970 permettait à une configuration de flux conçue de manière malveillante d’échapper à ces restrictions.

Un ticket de divulgation public de GitLab attribue le problème à un accès non sûr à des méthodes lors du rendu de modèles Jinja2. Jinja2 est un moteur de modèles Python qui combine du texte avec des variables et des expressions.

Selon le ticket, l’historique de conversation contenait un objet LangChain HumanMessage. Le modèle pouvait appeler une méthode publique de désérialisation sur cet objet. Une charge utile sérialisée non sûre entraînait alors l’exécution de commandes du système d’exploitation par Python durant la désérialisation.

La désérialisation reconvertit des données stockées ou transmises en objet de programme. Elle devient dangereuse lorsque le format sélectionné peut invoquer du code lors de la reconstruction de cet objet. Les données Python pickle constituent un exemple bien connu, car charger du contenu pickle non fiable est dangereux.

La preuve de concept rapportée utilisait un flux en deux étapes. La première interaction avec le modèle alimentait l’historique de conversation. Une évaluation ultérieure du modèle accédait à cet objet d’historique et déclenchait le chemin de désérialisation dangereux.

Cette séquence différencie le problème d’un simple bug d’injection de commandes shell. La valeur malveillante n’avait pas besoin d’apparaître comme paramètre de commande direct transmis à un shell. Plusieurs fonctionnalités ayant chacune un sens propre formaient plutôt la chaîne d’exécution.

Le flux acceptait du contenu de prompt configurable. Le moteur de modèles recevait des objets applicatifs. Un objet exposait une méthode de désérialisation. Le format de sérialisation accepté pouvait invoquer du code. Ensemble, ces conditions ont contourné le bac à sable prévu.

Le modèle lui-même n’était pas la frontière de sécurité de confiance. Il a contribué à faire progresser le flux entre les états, mais la commande s’est exécutée via un comportement applicatif déterministe. Filtrer uniquement la sortie du modèle ne résoudrait pas la relation vulnérable entre l’objet et le modèle.

Cette distinction est importante lorsque les organisations classifient les défaillances de sécurité de l’IA. L’injection de prompt décrit des tentatives de manipulation d’un modèle par des instructions. CVE-2026-90970 est une vulnérabilité logicielle dans le système qui entoure le modèle, même si un modèle de prompt fournit le point d’entrée.

Les pratiques traditionnelles de sécurité applicative restent donc essentielles. Les entrées des modèles nécessitent une validation stricte, les objets exposés doivent présenter des interfaces minimales, et les formats de désérialisation dangereux ne doivent pas traiter de données contrôlées par un attaquant. Les bacs à sable doivent également être testés contre les objets exacts mis à disposition en leur sein.

Les commandes rapportées s’exécutaient avec les privilèges du processus Duo Workflow Service. Cela limite l’autorité immédiate au niveau du système d’exploitation aux autorisations du compte de service. Toutefois, l’exécution au niveau du service reste grave, car la passerelle gère des connexions sensibles et se trouve au sein d’une infrastructure de confiance.

L’impact pratique dépend de l’architecture de déploiement. Un conteneur à privilèges minimaux avec une connectivité réseau restreinte présente moins de voies de propagation ultérieures qu’un service largement connecté. Aucune des deux configurations ne supprime la nécessité d’appliquer le correctif, car un attaquant obtiendrait toujours une exécution de code non prévue.

Ce mécanisme explique la gravité proche du maximum. L’attaquant commence avec une identité authentifiée capable d’utiliser Duo, mais l’exécution qui en résulte franchit le contexte de sécurité de la passerelle. Ce changement de portée est au cœur de la note de 9,9.

L’auto-hébergement transfère simultanément le contrôle et la responsabilité de sécurité

L’incident expose le compromis inhérent à une infrastructure d’IA auto-hébergée : conserver le traitement à proximité place aussi la passerelle dans la frontière de confiance opérationnelle du client.

GitLab décrit l’AI Gateway comme un service autonome reliant les fonctionnalités GitLab Duo aux modèles d’IA. Les clients peuvent utiliser la passerelle gérée par GitLab ou exploiter leur propre passerelle avec GitLab Duo Self-Hosted.

Les organisations choisissent souvent l’auto-hébergement afin de contrôler les mouvements de données, l’accès aux modèles, les routes réseau et la politique d’infrastructure. Ces avantages peuvent compter dans les environnements réglementés ou les déploiements soumis à des contrôles internes stricts. Ils créent aussi un service de production supplémentaire que les clients doivent inventorier et maintenir.

La vulnérabilité de GitLab AI Gateway transforme ce détail opérationnel en principal problème de sécurité. GitLab pouvait déployer directement un correctif sur les passerelles qu’il gère. Les clients auto-hébergés doivent planifier, exécuter et vérifier leurs propres mises à niveau.

Ce schéma est familier dans les bases de données, les services d’identité et les runners CI. La différence est que les passerelles d’IA rejoignent des systèmes autrefois plus clairement séparés. Elles se situent entre les utilisateurs, les dépôts de code source, les workflows d’agents, les fournisseurs de modèles et parfois les outils d’exécution.

Une passerelle compromise mérite donc davantage d’attention qu’une interface de chatbot isolée. Selon la configuration, elle peut traiter du contenu de prompt, l’état des workflows, des identifiants de service, des connexions aux fournisseurs ou des métadonnées sur l’activité de développement interne.

Cela n’établit pas que CVE-2026-90970 a exposé chaque secret connecté. L’avis de GitLab ne signale aucun vol de données confirmé ni chemin complet de post-exploitation. La conclusion correcte est que l’exécution arbitraire de commandes crée une voie crédible vers un accès supplémentaire.

Les équipes doivent évaluer la passerelle comme un service d’intégration privilégié. Son identité de processus, ses fichiers montés, ses variables d’environnement, ses routes réseau et les comptes de service qui lui sont attachés déterminent le rayon d’impact. Ces contrôles deviennent importants lors de la reconstitution de l’exposition avant l’application du correctif.

La conteneurisation n’aide que lorsque ses frontières sont délibérément configurées. Un conteneur peut toujours atteindre des services réseau, lire des secrets montés ou envoyer des données vers l’extérieur. Sa sécurité effective dépend des autorisations d’exécution et des politiques environnantes.

Le guide d’installation de GitLab recommande de restreindre l’accès réseau sortant du conteneur AI Gateway. Le contrôle du trafic sortant limite les destinations qu’un processus compromis peut contacter. Il peut réduire l’utilité d’une exécution de commandes, sans toutefois éliminer l’impact local.

La segmentation réseau apporte une autre couche de confinement. Une passerelle doit accéder à des points de terminaison GitLab et de modèles définis, mais elle a rarement besoin d’un accès sans restriction à l’ensemble d’un réseau interne. Des listes d’autorisation strictes compliquent les mouvements latéraux inattendus.

La conception des identifiants compte tout autant. Les secrets de longue durée stockés directement dans l’environnement constituent des cibles attrayantes après une compromission. Des identifiants à courte durée de vie, des comptes de service isolés et des autorisations étroitement limitées peuvent réduire les dommages après la compromission d’un service.

Les équipes de sécurité devraient aussi examiner qui peut créer ou modifier des flux personnalisés. La documentation de GitLab attribue les actions de gestion des flux à des rôles tels que Maintainer ou Owner dans plusieurs workflows. L’exposition exacte dépend néanmoins de la configuration du produit et de l’implémentation concernée.

L’avis utilise l’expression plus générale « accès à Duo Agent Platform » plutôt que de nommer un rôle de projet universellement requis. Les administrateurs ne devraient pas transformer des exemples de documentation en prérequis définitif d’exploitation. Ils devraient examiner les autorisations réelles et l’historique des modifications des flux.

L’auto-hébergement demeure un choix architectural valable. La leçon n’est pas qu’un service géré est toujours plus sûr. La leçon est que le contrôle des données, le contrôle du logiciel et la responsabilité des incidents arrivent ensemble.

Une passerelle gérée concentre la confiance dans les opérations du fournisseur. Une passerelle auto-hébergée concentre la confiance dans la gestion des correctifs, l’isolation et la surveillance du client. CVE-2026-90970 rend cet échange visible, car la frontière de remédiation suit exactement la frontière d’hébergement.

Pour les acheteurs d’entreprise, l’examen de sécurité devrait couvrir à la fois les fonctionnalités du produit et la responsabilité du déploiement. Les questions sur le parcours des données devraient être associées à des questions sur la personne qui applique les correctifs à chaque composant. Un diagramme d’architecture sans responsabilité opérationnelle reste incomplet.

Un correctif ferme la faille mais laisse des questions de détection

La mise à jour bloque le chemin vulnérable connu, mais l’avis public n’indique pas aux opérateurs comment prouver qu’aucune exploitation antérieure n’a eu lieu.

Au 4 octobre, GitLab n’avait pas déclaré publiquement que CVE-2026-90970 était exploitée dans la nature. Cette absence est rassurante, mais elle ne prouve pas que chaque déploiement concerné est resté intact.

Les détails techniques publics renforcent l’importance d’appliquer rapidement les correctifs. Le ticket de divulgation décrit la relation entre les objets vulnérables et signale une exécution de commandes réussie dans un environnement de préproduction. Défenseurs comme attaquants peuvent étudier ce matériel.

GitLab a crédité le chercheur HackerOne connu sous le nom de invisiblemeerkat pour la divulgation responsable. Ce signalement responsable a donné à GitLab le temps de préparer des correctifs et de contacter les clients concernés. Il n’a pas supprimé la fenêtre d’exposition pour les déploiements restant non corrigés après la publication.

L’exigence d’authentification devrait orienter la chasse aux menaces. Les équipes de sécurité devraient commencer par les identités Duo Agent Platform, les événements de gestion des flux et les modifications apportées aux définitions de flux personnalisés. Elles devraient corréler ces enregistrements avec l’activité de la passerelle pendant la période vulnérable.

Les configurations de flux inhabituelles méritent un examen, en particulier les modèles qui accèdent à des objets d’historique de conversation ou invoquent des méthodes. La création, la modification, la publication ou l’exécution inattendue de flux peut fournir un contexte supplémentaire. Des noms de flux ordinaires ne devraient pas écarter un comportement de modèle suspect.

L’activité des processus de la passerelle compte également. Les processus enfants, l’invocation d’un shell, les binaires inattendus, les accès inhabituels aux fichiers et les connexions sortantes peuvent indiquer une exécution de commandes. Les données utiles dépendent de la télémétrie déjà activée au niveau du conteneur, de l’hôte et du cloud.

Les redémarrages de conteneurs peuvent effacer des preuves locales. Les journaux centralisés et la télémétrie de sécurité à l’exécution sont donc plus utiles que l’inspection d’un seul conteneur actuellement en cours d’exécution. Les équipes devraient préserver les journaux disponibles avant de remplacer l’infrastructure si elles soupçonnent une compromission.

Les opérateurs devraient examiner les secrets accessibles au processus de la passerelle. Les décisions de rotation devraient s’appuyer sur les preuves et l’exposition, non sur la panique. Si les journaux indiquent une exécution de commandes, supposez que des identifiants lisibles ont pu être consultés.

Les connexions de la passerelle à GitLab et aux fournisseurs de modèles méritent une attention distincte. Un attaquant ayant obtenu l’exécution de commandes pourrait tenter de réutiliser des jetons, d’inspecter la configuration ou d’atteindre des services connectés. Les informations publiques ne confirment pas qu’une telle activité ait eu lieu.

Le correctif ne devrait pas marquer la fin de l’enquête lorsqu’il existe des éléments suspects. La mise à jour supprime le chemin de code connu, mais elle ne révoque pas des identifiants volés ni n’annule des modifications effectuées ailleurs. Les procédures de réponse aux incidents restent nécessaires.

Il existe aussi une raison historique de rester prudent. Des rapports de sécurité ont identifié une précédente vulnérabilité AI Gateway en 2026, CVE-2026-1868, avec le même score de 9,9 et la même catégorie de faiblesse CWE-1336. Cette faille impliquait également du contenu de flux conçu de manière malveillante et une possible exécution de code.

Deux problèmes de moteur de modèles à haute gravité ne prouvent pas que chaque flux personnalisé est dangereux. Ils justifient un examen plus approfondi de la manière dont les modèles, les objets applicatifs et la sérialisation se rencontrent dans les systèmes d’agents.

Cette récurrence suggère que les tests de sécurité doivent couvrir les compositions, pas seulement les composants isolés. Un bac à sable peut se comporter correctement avec des chaînes de caractères tout en échouant lorsque des objets riches du framework entrent dans son contexte. Une méthode sûre dans une couche peut devenir dangereuse lorsque des modèles peuvent l’invoquer.

Les plateformes d’agents intensifient ce problème parce qu’elles réunissent de nombreux mécanismes flexibles. Prompts, outils, historiques, logique de routage, réponses de modèles et API applicatives interagissent au fil d’étapes répétées. Un état introduit à une étape peut devenir une entrée exécutable plus tard.

Les organisations devraient ajouter des flux personnalisés adversariaux aux tests avant déploiement. Les tests devraient inclure l’accès aux méthodes, le parcours d’objets, les frontières de sérialisation et les changements d’état en plusieurs étapes. Une analyse de prompt en un seul passage ne représenterait pas la chaîne d’exploitation signalée.

Elles devraient aussi traiter les modèles comme des artefacts proches du code. Leur revue, leur propriété, leur historique de modification et leurs contrôles de déploiement devraient correspondre à leur impact potentiel. Qualifier un fichier de « configuration » ne réduit pas sa capacité à modifier le comportement d’exécution.

GitLab n’a pas détaillé publiquement toutes les conditions nécessaires à l’exploitation. Cela limite une évaluation confiante de l’exposition. Les équipes devraient utiliser les prérequis divulgués comme conditions minimales, sans supposer que des conditions non précisées garantissent la sécurité.

Trois signaux montreront si la réponse fonctionne

La prochaine phase dépend de l’adoption des correctifs, d’éléments prouvant une exploitation réelle et d’un traitement plus approfondi par GitLab de l’isolation des flux personnalisés.

Le premier signal est le pourcentage de passerelles auto-hébergées exécutant 19.2.4, 19.3.2, 19.4.1 ou une version corrigée ultérieure. Chaque organisation devrait le mesurer dans tous les environnements et répliques. Les chiffres à l’échelle du secteur pourraient rester indisponibles, car ces déploiements résident dans les réseaux des clients.

Une adoption rapide réduirait la surface d’attaque accessible après la divulgation publique. Une adoption lente prolongerait le risque, en particulier lorsque les services d’IA échappent aux inventaires établis de gestion des vulnérabilités. La responsabilité de la passerelle devrait devenir visible dans les tableaux de bord des correctifs.

Le deuxième signal est tout changement du statut d’exploitation. GitLab, CISA, les sociétés de réponse aux incidents et les clients concernés pourraient publier des indicateurs ou des cas confirmés. Un signalement d’exploitation active ferait passer la priorité de l’application préventive des correctifs à une réponse aux incidents plus large.

Les défenseurs devraient distinguer une preuve de concept publique d’attaques observées. Une reproduction technique prouve que la faille fonctionne dans les conditions documentées. Elle n’établit pas que des attaquants ont compromis des clients en production.

Le troisième signal est une évolution structurelle de la sécurité dans AI Gateway. Un correctif ciblé peut bloquer l’appel de méthode divulgué. Une réponse plus large pourrait réduire les objets atteignant les modèles, interdire les sérialisations dangereuses ou renforcer l’isolation autour des flux personnalisés.

Cette réponse de conception importe parce que la chaîne signalée est née de la composition de fonctionnalités. Empêcher une charge utile est utile, mais éliminer la frontière de capacité non sûre apporte une protection plus forte contre les variantes.

Les futures notes de version et modifications de code de GitLab devraient clarifier quelle couche a reçu le correctif. Les administrateurs devraient surveiller les nouvelles recommandations couvrant la validation des flux, les événements d’audit, les requêtes de détection et les chemins de mise à niveau pris en charge pour les anciennes branches de la passerelle.

Les clients d’entreprise peuvent utiliser cet incident pour tester dès maintenant leur propre modèle d’exploitation. La question importante n’est pas simplement de savoir si GitLab figure dans l’inventaire logiciel. Il s’agit de déterminer si AI Gateway existe en tant que service séparément détenu, corrigé, journalisé et isolé.

Les développeurs qui créent des flux devraient aussi reconsidérer la confiance accordée à la configuration. Un flux personnalisé peut coordonner des outils et des données applicatives au fil de plusieurs étapes. Il devrait susciter le même scepticisme que les scripts d’automatisation et les définitions CI.

Les réviseurs de sécurité devraient cartographier quatre frontières : qui peut créer des flux, à quels objets les modèles peuvent accéder, quels outils les flux peuvent invoquer et quels privilèges détient le processus de la passerelle. Une faiblesse sur plusieurs frontières peut transformer un accès limité en contrôle de l’infrastructure.

Les travailleurs du savoir utilisant GitLab Duo n’ont pas besoin d’abandonner leur travail ordinaire à cause de cet avis. La plupart ne peuvent pas déterminer eux-mêmes qui possède la passerelle. Ils devraient suivre les consignes de leur organisation et signaler les comportements inattendus des flux plutôt que de tenter des tests indépendants.

Les administrateurs font face à une action plus claire. Identifiez le modèle d’hébergement, confirmez la version de la passerelle en cours d’exécution, déployez le correctif approprié et préservez les preuves lorsque des activités suspectes apparaissent. Examinez les modifications de flux et la télémétrie de la passerelle sur l’ensemble de la période vulnérable.

Après l’application du correctif, documentez le résultat dans un registre opérationnel durable. Consignez la version précédente, l’heure de déploiement, les environnements concernés, la méthode de vérification et tout résultat de chasse aux menaces. Ces éléments étayent les audits futurs et la reconstitution d’incidents.

La vulnérabilité GitLab AI Gateway est avant tout un avertissement sur le point où la logique applicative d’IA devient un logiciel exécutable conventionnel. La défaillance a commencé dans un modèle de prompt, a traversé un objet de framework et s’est terminée par des commandes du système d’exploitation.

Ce chemin mérite davantage d’attention que la seule étiquette « IA ». Les modèles peuvent influencer les workflows, mais les frontières logicielles ordinaires déterminent toujours si une entrée non fiable devient du code. Les organisations ont besoin de contrôles autour de ces deux couches.

Si votre organisation exploite GitLab Duo, posez-vous aujourd’hui une question concrète : qui possède la passerelle qui traite ces requêtes ? Si la réponse est votre équipe, vérifiez sa version par rapport aux versions corrigées de GitLab. Testez ensuite si votre surveillance révélerait des commandes inattendues, des flux modifiés ou des connexions sortantes. Le correctif ferme la vulnérabilité GitLab AI Gateway divulguée, mais une sécurité durable dépend d’un inventaire, d’une isolation et de preuves qui résistent au prochain avis.