GitLab : la faille notée 10/10 est exploitée, et Ruby doit suivre

Le 22 octobre, nous vous alertions sur une faille GitLab notée 10 sur 10 et rappelions qu'une autre, du même type, avait été corrigée dix jours plus tôt. C'est cette dernière, CVE-2026-97229, qui est désormais exploitée par des attaquants. Selon The Hacker News, la CISA américaine l'a ajoutée le 29 octobre à son catalogue des vulnérabilités activement exploitées (KEV).

La victime connue est le projet Alpine Linux, l'une des distributions Linux les plus utilisées dans les conteneurs. Et son retour d'expérience contient une leçon que beaucoup d'équipes n'ont pas encore intégrée : sur certaines installations, mettre GitLab à jour ne suffit pas.

Ce que l'on sait

La faille : un dépassement d'entier dans la compilation des expressions régulières, atteignable via la configuration CI/CD. Selon The Hacker News, elle permet à un attaquant non authentifié d'exécuter du code sur le serveur GitLab.
Gravité : CVSS 10,0, le maximum.
Correctif : publié par GitLab le 12 octobre dans les versions 19.4.2, 19.3.5 et 19.2.8, selon Help Net Security. Les versions publiées le 21 octobre (19.5.1, 19.4.3, 19.3.6, 19.2.9) corrigent en plus CVE-2026-110264.
Cause profonde : selon Alpine Linux, le bogue se trouve dans Onigmo, le moteur d'expressions régulières intégré à Ruby. Le correctif de GitLab est en réalité un ensemble de patchs appliqués au Ruby que GitLab embarque dans ses propres paquets et images.
Exploitation : selon The Hacker News, l'ajout au catalogue KEV s'appuie sur l'incident divulgué par Alpine Linux. Les agences fédérales américaines sont invitées à corriger d'ici le 1er novembre.

Ce qui s'est passé chez Alpine Linux

Le projet a publié le 28 octobre un compte rendu détaillé. Les points clés :

les 20 et 21 octobre, un compte nouvellement créé a envoyé des configurations CI/CD piégées à l'instance GitLab du projet ;
l'attaque a fait planter les processus GitLab huit fois. Dans quatre cas, l'attaquant est allé jusqu'à mi-chemin de l'exploitation avant d'échouer ;
l'attaquant a téléchargé l'image de conteneur GitLab d'Alpine, ce qui suggère qu'il ajustait son exploit à la version exacte utilisée ;
de nouvelles tentatives les 25 et 26 octobre ont échoué.

Alpine écrit que « l'attaque a failli réussir ». Le projet n'a trouvé aucune preuve d'exécution de code, mais ne peut pas l'exclure : il a donc traité l'instance comme compromise, l'a reconstruite entièrement, a réinitialisé tous les mots de passe et remplacé les clés secrètes de GitLab. Selon Alpine, ses paquets et ses versions publiées n'ont pas été modifiés, et ses clés de signature n'ont jamais été stockées sur ce serveur.

Pourquoi la mise à jour n'a pas suffi

C'est le point le plus important pour les entreprises. Alpine a d'abord installé par erreur une version sans le correctif. Mais même après être passé à une version corrigée, son instance est restée vulnérable. La raison : son image utilisait le Ruby standard, et non le Ruby patché livré par GitLab dans ses paquets officiels.

Ruby n'a publié ses propres versions corrigées que le 23 octobre : 3.3.13, 3.4.12 et 4.0.9. Les versions 3.2 et antérieures ne reçoivent aucun correctif.

Concrètement :

paquets Linux officiels (Omnibus) et images Docker officielles de GitLab : le Ruby corrigé est inclus, la mise à jour de GitLab suffit ;
installation depuis les sources ou image maison avec son propre Ruby : il faut mettre à jour GitLab et Ruby, puis redémarrer les services ;
GitLab.com et GitLab Dedicated : aucune action n'est nécessaire.

Les mesures à prendre maintenant

Vérifier la version de chaque instance GitLab auto-hébergée, y compris celles gérées par un prestataire ou installées pour un projet.
Vérifier comment elle est installée. Si ce n'est pas un paquet ou une image officielle de GitLab, contrôlez la version de Ruby réellement utilisée.
Fermer l'inscription libre si elle n'est pas indispensable : chez Alpine, l'attaque a commencé par la création d'un compte.
Chercher des traces. Des plantages répétés de GitLab, des erreurs 502 ou des échecs de jobs CI inexpliqués depuis la mi-octobre méritent une analyse.
En cas de doute, faire comme Alpine. Si une instance exposée n'était pas réellement corrigée, renouvelez les secrets CI/CD, les jetons et les clés de déploiement, et envisagez une reconstruction.

Notre regard

Cet incident illustre un piège classique : une mise à jour peut être appliquée sans que la faille soit corrigée, parce que le code vulnérable se trouve dans une dépendance que l'on gère soi-même. Le numéro de version affiché rassure, la réalité technique est différente. Seul un contrôle de ce qui tourne réellement permet de le savoir.

C'est ce que nous vérifions lors de nos tests d'intrusion. Et si vous craignez qu'une instance ait déjà été visée, notre pôle forensic peut l'analyser. Contactez-nous.