Alpine Linux avait mis à jour GitLab, mais sa faille critique se cachait dans le langage Ruby

Le 21 octobre, le serveur GitLab d'Alpine Linux, une distribution Linux très utilisée dans les conteneurs, se met à planter. Les pages renvoient des erreurs, les chaînes de compilation échouent. Derrière ces pannes, un compte créé la veille envoie des configurations d'intégration continue fabriquées pour exploiter une faille de GitLab.

Cette faille, CVE-2026-97229, est notée 10 sur 10. Selon GitLab, elle pourrait permettre à une personne sans compte d'exécuter du code sur le serveur au moyen d'une expression régulière piégée placée dans une configuration CI/CD. GitLab a publié son correctif le 12 octobre. Le 29 octobre, l'agence américaine de cybersécurité (CISA) l'a ajoutée à son catalogue des failles activement exploitées.

Huit plantages, et une incertitude

Alpine a raconté l'incident en détail sur son site. L'attaquant a fait tomber les processus de GitLab à huit reprises. Quatre fois, il a mené son exploit en partie avant d'échouer à l'étape suivante. Il a aussi téléchargé l'image de conteneur GitLab d'Alpine : selon la distribution, cela suggère qu'il ajustait son attaque à cette installation précise.

A-t-il réussi ? « Nous n'avons trouvé aucune preuve de succès, mais nous ne pouvons pas l'exclure », écrit Alpine. Une exploitation réussie ne laisserait ni plantage ni trace dans les journaux web. Or une partie des journaux du 21 octobre a disparu, et les connexions sortantes n'étaient pas enregistrées. Alpine a donc traité son serveur comme compromis.

Pourquoi la mise à jour de GitLab n'a rien changé

C'est le point qui concerne bien d'autres organisations. Le défaut ne se trouve pas dans le code de GitLab mais dans Onigmo, le moteur d'expressions régulières intégré au langage Ruby. Les paquets officiels de GitLab embarquent un Ruby corrigé. L'image d'Alpine, elle, utilisait un Ruby standard.

Au moment de l'attaque, l'instance tournait en GitLab 19.3.4 : le 13 octobre, Alpine avait installé cette version par erreur au lieu de la 19.3.5, qui contenait le correctif. Et même passée en GitLab 19.3.6 le 22 octobre, l'installation est restée vulnérable. « La mise à jour vers GitLab 19.3.6 le 22 octobre n'a pas corrigé la faille », reconnaît Alpine. Ruby a publié ses propres correctifs le 23 octobre. L'attaquant est revenu les 25 et 26 octobre, sans succès. Le 27 octobre, Alpine a fermé son GitLab au public et l'a reconstruit de zéro.

Alpine affirme que les clés qui signent ses paquets et ses versions n'ont jamais été stockées sur ce serveur. Ses dépôts, ses paquets et les versions publiées le 21 octobre ont été contrôlés à partir de copies extérieures, sans trace de modification. Tous les mots de passe ont été réinitialisés et les clés secrètes de GitLab remplacées.

Que vérifier sur votre propre GitLab ?

Si vous utilisez les paquets officiels de GitLab, appliquez le correctif publié par l'éditeur. Si votre GitLab tourne avec un autre Ruby (installation depuis les sources, image de conteneur maison ou tierce), la mise à jour de GitLab ne suffit pas :

• passez Ruby en version 3.3.13, 3.4.12, 4.0.9 ou ultérieure ;
• si vous utilisez l'image alpinelinux/gitlab, téléchargez à nouveau la version 19.3.6 : selon Alpine, toute image 19.3.6 récupérée avant le 27 octobre, et toutes les versions plus anciennes, sont vulnérables ;
• sous Alpine, lancez apk upgrade pour obtenir le Ruby corrigé ;
• vérifiez dans vos journaux si des configurations CI/CD inhabituelles ont fait planter vos processus GitLab depuis mi-octobre ;
• sur un serveur ouvert aux inscriptions, surveillez les comptes récents.

En cas de doute, Alpine a fait le choix prudent : réinitialiser tous les mots de passe et remplacer les clés secrètes de GitLab. Selon la distribution, les variables CI/CD et les jetons des exécutants figurent parmi les données qu'un attaquant aurait pu atteindre.

Combien d'autres serveurs visés ?

Alpine est la seule cible connue à ce jour, et c'est sa transparence qui a révélé l'attaque. La CISA ne dit pas si elle a observé d'autres tentatives. La faille touche en réalité tout programme Ruby qui compile des expressions régulières venues de l'extérieur : GitLab n'est peut-être que la cible la plus visible.