Vulnérabilité CVSS 10 dans GitLab : le sens de « non authentifié » dépend des personnes qui peuvent créer des projets sur votre serveur

Si vous utilisez une instance GitLab autogérée (self-managed) dans les branches 19.2, 19.3 ou 19.4, prévoyez une mise à jour dès aujourd’hui. Le 12 octobre 2026, GitLab a publié des versions qui corrigent 24 vulnérabilités. L’une d’elles atteint un score CVSS de 10.0 : une expression régulière spécialement conçue dans une configuration CI/CD peut entraîner l’exécution de code sur le serveur GitLab.

Les titres de presse indiquent qu’un utilisateur non authentifié peut exécuter du code sur le serveur. L’avis de GitLab est plus prudent. Il précise que cela est possible « dans certaines conditions », sans les détailler. Selon The Hack Academy, la méthode d’exploitation démontrée par Rapid7 dépend notamment des personnes autorisées à créer des projets et à écrire des configurations CI/CD sur votre serveur.

Ce que publie GitLab

Selon l’avis de correctif de GitLab, les versions 19.4.2, 19.3.5 et 19.2.8 de Community Edition et d’Enterprise Edition ont été publiées le 12 octobre 2026. GitLab recommande vivement de mettre immédiatement à niveau toute instance autogérée vers l’une de ces versions. Selon l’avis, GitLab.com utilise déjà une version corrigée et les clients GitLab Dedicated n’ont aucune action à effectuer.

La principale vulnérabilité est CVE-2026-97229. L’avis la décrit comme un dépassement d’entier (integer overflow) dans le compilateur d’expressions régulières de CI/CD. Selon l’avis, dans certaines conditions, elle aurait pu permettre à un utilisateur non authentifié d’exécuter du code arbitraire sur le serveur GitLab au moyen d’une expression régulière spécialement conçue dans une configuration CI/CD. L’avis attribue cette vulnérabilité à une validation insuffisante des expressions régulières.

• Versions concernées : CE/EE, de 19.2 à toute version antérieure à 19.2.8, de 19.3 à toute version antérieure à 19.3.5, et de 19.4 à toute version antérieure à 19.4.2.
• Gravité : Critical, CVSS 10.0. Selon le vecteur publié, la vulnérabilité est exploitable par le réseau, la complexité de l’attaque est faible et aucun privilège ni aucune interaction d’un utilisateur ne sont nécessaires.
• Signalement : joaxcar, par le programme de bug bounty de GitLab sur HackerOne.

D’autres précisions de l’avis sont importantes pour préparer la mise à jour :

• 19.3.5, pas 19.3.4. Selon l’avis, la version 19.3.4 comportait un bug qui affectait les pages de merge request lorsque l’intégration Ona était activée. Ce bug a été corrigé dans 19.3.5.
• Les autres correctifs. Outre la vulnérabilité critique, l’avis recense cinq vulnérabilités de gravité High. Elles comprennent une XSS dans la coloration syntaxique (8.7) et une vulnérabilité permettant à un utilisateur ayant le rôle Developer d’exécuter sans autorisation des pipelines sur des branches protégées (8.5). Selon l’avis, trois vulnérabilités de gravité Medium permettent à un utilisateur non authentifié de lire des notes confidentielles ou le contenu de work items auxquels il ne devrait pas avoir accès.
• Correctifs pour Ruby. La liste des corrections de bugs de chacune des trois versions contient des correctifs pour les expressions régulières dans Ruby 3.3 et 3.4. L’avis ne les relie pas explicitement à la CVE.
• Les détails complets dans 90 jours. Selon la politique de GitLab, les issues décrivant chaque vulnérabilité sont rendues publiques 90 jours après la publication de la version qui la corrige.
• Interruption de service. Ces versions comprennent des migrations de base de données. Sur une installation à serveur unique, la mise à jour entraînera une interruption de service : les migrations doivent être terminées avant le démarrage de GitLab. Sur une installation à plusieurs serveurs, la mise à jour peut se faire sans interruption, selon la procédure zero-downtime. La version 19.3.5 comprend aussi des migrations exécutées après le déploiement.

L’avis ne propose aucune mesure de contournement temporaire.

Ce que signifie « non authentifié » en pratique

GitLab n’explique pas quelles sont ces conditions particulières. Selon The Hack Academy, Rapid7 a publié sa propre analyse le 13 octobre. D’après cet article, les chercheurs de Rapid7 ont reproduit une exécution de code sur l’image officielle de GitLab 19.4.1 Community Edition, mais la même entrée n’a pas entraîné d’exécution de code sur l’image officielle de 19.4.2. Selon Rapid7, le code s’exécutait dans le processus Ruby sous le compte git de GitLab.

Selon The Hack Academy, la méthode d’exploitation démontrée exigeait que l’attaquant contrôle la configuration CI/CD d’un projet public, ainsi que d’autres conditions propres au projet. Rapid7 a précisé que, sur un serveur où les inscriptions sont ouvertes et où les nouveaux utilisateurs peuvent créer des projets, un compte tout juste créé suffit à remplir cette condition. Autrement dit, « non authentifié » désigne ici toute personne capable de créer un compte sur votre serveur. Selon l’article, Rapid7 a décrit une méthode d’exploitation sans affirmer qu’il n’en existait pas d’autres.

Pour les administrateurs qui ne peuvent pas mettre à jour immédiatement, Rapid7 a proposé de restreindre l’accès anonyme aux projets publics et d’empêcher les utilisateurs non fiables de créer des projets publics ou d’y écrire. Selon The Hack Academy, Rapid7 a souligné que ces mesures ne réduisent l’exposition qu’à la méthode d’exploitation démontrée. Elles ne corrigent pas le compilateur vulnérable.

Les imprécisions de la couverture médiatique

Le titre de The Hacker News. L’article s’intitule « GitLab corrige une faille CVSS 10.0 qui pourrait permettre à des utilisateurs non authentifiés d’exécuter du code sur le serveur ». Le corps de l’article cite l’avis dans son intégralité, y compris la réserve « dans certaines conditions », mais le titre l’omet. Une personne qui ne lit que le titre pourrait en déduire que toute personne ayant accès à un serveur GitLab vulnérable peut y exécuter du code, quelle que soit sa configuration. Ce n’est pas ce que dit l’avis de GitLab. D’après la reproduction de Rapid7, la méthode d’exploitation démontrée dépend de la configuration du serveur.

Le nombre de vulnérabilités de gravité High. L’article de The Hacker News indique que trois vulnérabilités de gravité High ont été corrigées en plus de la vulnérabilité critique. Le tableau de GitLab en recense cinq. Les deux autres ne concernent qu’Enterprise Edition : CVE-2026-81839 (politique d’exécution planifiée des pipelines, 7.7) et CVE-2026-96893 (injection de contenu dans les instructions d’un agent IA dans Duo Agent Platform, 7.3). Les administrateurs qui utilisent EE doivent aussi en tenir compte.

Ce qui ne s’est pas produit

Selon The Hack Academy, aucune des sources consultées n’a signalé d’exploitation de CVE-2026-97229 en conditions réelles. Rapid7 a écrit qu’au 13 octobre, il n’existait aucune preuve confirmée d’exploitation sur le terrain. Cybersecurity Dive a indiqué le 12 octobre qu’on ignorait si des attaquants avaient commencé à exploiter la vulnérabilité et que celle-ci ne figurait pas dans le catalogue KEV de la CISA ce matin-là. Ces informations ne valent qu’à leur date de publication. Selon The Hack Academy, Rapid7 a réalisé sa reproduction en laboratoire et le code n’a pas été publié.

La reproduction elle-même a ses limites. Elle montre qu’une méthode d’exploitation fonctionne, pas qu’elle est la seule. Tant que les détails complets ne sont pas publics, des questions restent ouvertes. Selon The Hack Academy, on ignore s’il existe d’autres méthodes d’exploitation, quelle est la cause racine exacte et quels indicateurs fiables permettraient de détecter une exploitation. Le score CVSS exprime la gravité de la vulnérabilité, pas le degré d’exposition de votre serveur. L’exposition réelle dépend des personnes qui peuvent créer des projets sur le serveur et des utilisateurs dont les configurations CI/CD y sont traitées.

Ne confondez pas cette vulnérabilité avec les précédentes vulnérabilités de GitLab. The Hacker News mentionne CVE-2026-85706, une vulnérabilité antérieure notée 10.0 qui, selon l’article, a fait l’objet de tentatives d’exploitation sur le terrain dans les heures suivant sa divulgation. D’après la couverture médiatique, il s’agit d’une autre vulnérabilité, avec une cause et une plage de versions différentes. Ce qui a suivi sa divulgation ne permet pas de tirer de conclusion sur CVE-2026-97229, mais rappelle que le délai entre une divulgation et les premières tentatives d’exploitation peut être très court.

Ce que cela implique pour votre serveur

Mettez à jour vers la version correspondant à votre branche

Passez à 19.2.8, 19.3.5 ou 19.4.2. Pour la branche 19.3, passez à 19.3.5 et non à 19.3.4. Si vous utilisez un serveur unique, prévoyez une fenêtre d’interruption pour les migrations. Après la mise à jour, vérifiez que la version effectivement exécutée est bien la version corrigée.

Vérifiez qui peut s’inscrire et créer des projets

D’après la reproduction de Rapid7, la question décisive est de savoir si une personne extérieure peut créer un compte et écrire une configuration CI/CD dans un projet public. Sur un serveur destiné à une équipe interne, il n’y a généralement pas de raison de laisser les inscriptions ouvertes. Vérifiez si les inscriptions sont ouvertes, si les nouveaux utilisateurs peuvent créer des projets et qui peut créer des projets publics. Ces possibilités doivent rester limitées même après la mise à jour, car elles déterminent la rapidité avec laquelle n’importe qui sur Internet pourra exploiter la prochaine vulnérabilité de CI/CD.

Si les inscriptions étaient ouvertes, examinez ce qui a été créé

Sur un serveur où les inscriptions étaient ouvertes pendant que la version vulnérable était utilisée, examinez les comptes et les projets publics créés récemment, ainsi que leurs configurations CI/CD. Il ne s’agit pas d’indicateurs d’exploitation publiés : selon les articles, ces indicateurs ne sont pas encore connus. C’est un point de départ raisonnable pour les vérifications.

Limitez les destinations accessibles au serveur GitLab

Selon Rapid7, le code s’exécutait sous le compte git. Un serveur GitLab a besoin de connexions sortantes légitimes, par exemple pour l’importation de dépôts, les webhooks et les miroirs. Recensez les destinations auxquelles le serveur doit réellement se connecter et limitez l’accès aux autres destinations dans le pare-feu. Le même ensemble de correctifs corrige aussi une vulnérabilité SSRF dans l’importation de dépôts qui, selon l’avis, permettait d’atteindre des ressources du réseau interne. C’est une raison supplémentaire d’isoler autant que possible le serveur GitLab du réseau interne.

Comment nuDefend aide

nuDefend s’exécute sur votre serveur Linux et met en œuvre deux couches de protection indépendantes. Au niveau réseau, le trafic à destination et en provenance d’adresses IP connues comme malveillantes est bloqué dans le pare-feu du noyau. Ces adresses comprennent des serveurs de commande et de contrôle de botnets, des scanners actifs et des infrastructures de logiciels malveillants. Au niveau DNS, les domaines dangereux sont neutralisés sur l’ensemble du système : aucune application du serveur ne peut les résoudre ni les joindre. Les listes de menaces sont signées cryptographiquement et mises à jour automatiquement.

Le tableau de bord affiche un compteur du trafic sortant bloqué. Une valeur supérieure à zéro peut servir d’alerte précoce : quelque chose sur le serveur a tenté de contacter un serveur externe.

La commande nudefend expose affiche chaque service en écoute sur le serveur et indique qui peut y accéder, du point de vue du serveur lui-même. Si un service jusque-là uniquement interne devient accessible de l’extérieur, nuDefend détecte ce changement et émet une alerte. Vous pouvez bloquer un port exposé depuis le tableau de bord ou la ligne de commande, après un aperçu montrant exactement ce qui sera bloqué. Si les utilisateurs de votre serveur GitLab se trouvent dans un nombre limité de pays, vous pouvez aussi utiliser le blocage par pays pour n’autoriser l’accès que depuis les pays choisis. Vous trouverez plus de détails dans la documentation.

En résumé

CVE-2026-97229 est notée 10.0 et GitLab recommande une mise à jour immédiate. Passez à 19.2.8, 19.3.5 ou 19.4.2. L’avis précise que l’exploitation est possible « dans certaines conditions ». D’après la reproduction de Rapid7, la méthode d’exploitation démontrée exige de pouvoir contrôler la configuration CI/CD d’un projet public. Selon The Hack Academy, Rapid7 a précisé que, sur un serveur où les inscriptions sont ouvertes et où les nouveaux utilisateurs peuvent créer des projets, un compte tout juste créé suffit. Après la mise à jour, vérifiez qui peut s’inscrire et créer des projets sur votre serveur, puis limitez les destinations accessibles au serveur GitLab.