GitLab CVE-2026-97229 : la CISA la signale comme exploitée, et Alpine Linux montre que la mise à jour ne suffit pas toujours

La CISA a inscrit CVE-2026-97229, une faille de GitLab notée 10,0 sur l’échelle CVSS, à son catalogue des vulnérabilités exploitées. Alpine Linux fait état d’une tentative d’attaque contre son propre serveur, resté vulnérable après une mise à jour car le correctif dépend aussi de la version de Ruby utilisée.

Ce qui s’est passé

Le 29 octobre 2026, la CISA a inscrit CVE-2026-97229 à son catalogue des vulnérabilités exploitées : les agences fédérales américaines ont jusqu’au 1er novembre pour agir et doivent mener une analyse forensique. GitLab classe la faille comme critique, avec un score CVSS de 10,0. Un dépassement d’entier dans le compilateur des expressions régulières utilisées par la configuration CI/CD permet, sous certaines conditions, à un utilisateur non authentifié d’exécuter du code sur le serveur. L’éditeur l’a corrigée le 12 octobre dans les versions 19.4.2, 19.3.5 et 19.2.8. Alpine Linux a indiqué le 28 octobre qu’un attaquant avait tenté de l’exploiter contre le serveur GitLab du projet les 20 et 21 octobre.

Qui est concerné et comment les attaquants entrent

Sont touchées les éditions Community et Enterprise autogérées à partir de la 19.2 ; GitLab.com et Dedicated sont déjà corrigés. Le bug se niche dans Onigmo, le moteur d’expressions régulières intégré à Ruby, et le correctif de GitLab modifie le Ruby livré dans ses paquets et images officiels. Alpine a d’abord installé la 19.3.4 par erreur, puis une 19.3.6 dans une image bâtie sur le Ruby standard, donc sans le correctif. Avec un compte tout juste créé et des configurations CI piégées, l’attaquant a fait planter huit fois des processus GitLab. Alpine n’a trouvé aucune preuve d’exécution de code, mais faute de pouvoir l’exclure, le projet a reconstruit le serveur de zéro, réinitialisé tous les mots de passe et remplacé les clés secrètes de GitLab. Il affirme que ses versions et paquets ont été vérifiés et n’ont pas été modifiés, et que les clés de signature n’ont jamais résidé sur ce serveur.

Que faire maintenant

  1. Relevez votre version avec sudo gitlab-rake gitlab:env:info.
  2. Passez au dernier correctif de votre branche : 19.5.3, 19.4.5, 19.3.7 ou 19.2.10.
  3. Si vous compilez GitLab vous-même (depuis les sources ou dans votre propre conteneur), contrôlez ruby -v : il faut 3.3.13, 3.4.12, 4.0.9 ou plus récent. Retéléchargez alpinelinux/gitlab:19.3.6 si vous l’avez récupérée avant le 27 octobre ; les étiquettes plus anciennes sont vulnérables.
  4. Cherchez des traces : appliquez les six règles de détection publiées par GitLab et examinez les plantages de processus, les erreurs 502, les tâches CI en échec et les comptes récents. Un résultat vierge ne prouve pas grand-chose : d’après Alpine, une exploitation réussie ne laisse ni plantage ni trace dans les journaux web.
  5. En cas de doute, reconstruisez et renouvelez clés secrètes, mots de passe, variables CI/CD, jetons de runners et secrets de webhooks. Exigez une validation par un administrateur pour les nouveaux comptes.
  6. Passez en revue vos autres applications Ruby : tout code qui transmet une entrée non fiable à Regexp.new, Regexp.union ou à un motif interpolé a besoin d’un Ruby corrigé. Selon l’équipe de Ruby, ni Regexp.timeout ni une limite de longueur ne protègent de façon fiable.

Notre avis

Un numéro de version ne prouve pas qu’un serveur est corrigé quand le correctif se trouve dans une dépendance : le contrôle doit porter sur l’ensemble de la construction, surtout pour les images maison. Une forge concentre le code source et les secrets de déploiement ; elle n’a pas à rester ouverte à tout Internet. Conservez assez de journaux, connexions sortantes comprises, pour pouvoir répondre le jour où la question d’une compromission se pose.

Sources

Comment nous choisissons, vérifions et rédigeons nos analyses →

Votre propre serveur est-il exposé ? Faites un test gratuit — informations publiques uniquement, sans intrusion :

Tester un serveur Tester un site

Vous craignez que vos serveurs soient exposés ? Notre équipe audite, corrige et surveille vos infrastructures Linux et cloud 24h/24, 7j/7.

Parler à un expert Notre offre d’infogérance de serveurs →