Alpine Linux reconstruit son GitLab après qu’un attaquant a exploité la faille GitLab que son propre Ruby laissait ouverte
Le 28 octobre 2026, Alpine Linux a révélé qu’un attaquant avait tenté d’exploiter la CVE-2026-97229 (CVSS 10,0) contre son serveur GitLab, une semaine après le correctif de GitLab. La leçon dépasse Alpine : pour une installation GitLab compilée avec un Ruby maison, mettre à jour GitLab ne suffit pas, il faut aussi mettre à jour Ruby.
28 octobre 2026. Alpine Linux a révélé qu’un attaquant a tenté d’exploiter la CVE-2026-97229 — une faille GitLab notée CVSS 10,0 — contre son propre serveur GitLab, une semaine après la publication du correctif. Le projet n’a trouvé aucune preuve que l’attaque a abouti, mais ne peut pas l’exclure : il a donc reconstruit le serveur de zéro et réinitialisé le mot de passe de chaque compte. Le point qui compte : la faille n’était pas dans GitLab à proprement parler, mais dans le Ruby que Alpine compilait lui-même — et « mettre à jour GitLab ne suffit pas ».
Un serveur critique, un correctif qui ne corrigeait rien
Le serveur visé, gitlab.alpinelinux.org, héberge aports, le dépôt à partir duquel tous les paquets Alpine Linux sont construits. C’est un nœud de supply chain au sens fort : le compromettre, c’est potentiellement empoisonner les minirootfs qui servent de base aux images Docker officielles d’Alpine, distribuées à des millions de conteneurs.
La CVE-2026-97229 permet à un attaquant d’exécuter du code sur un serveur GitLab au moyen d’une expression régulière forgée dans une configuration CI. Le correctif publié par GitLab le 12 octobre consiste en un ensemble de correctifs appliqués au Ruby embarqué dans ses paquets et ses images officielles. Or l’image GitLab d’Alpine utilisait un Ruby standard, pas celui de GitLab : la mise à niveau vers GitLab 19.3.6 le 22 octobre n’a donc pas fermé la faille.
C’est là que l’incident devient une leçon. Pour quiconque fait tourner GitLab sur son propre Ruby — compilé depuis les sources ou dans une image conteneur maison — « mettre à niveau GitLab ne suffit pas », écrit Alpine. Ces serveurs doivent aussi passer à Ruby 3.3.13, 3.4.12, 4.0.9 ou plus récent. Les utilisateurs de l’image alpinelinux/gitlab doivent, eux, re-tirer la version 19.3.6.
Huit crashs, quatre tentatives à mi-chemin
La chronologie publiée par Alpine est précise, et c’est ce qui en fait un document rare. Le 13 octobre, le projet a mis à niveau le serveur vers GitLab 19.3.4 au lieu de 19.3.5 — une erreur qu’il assume. Le serveur est resté sur cette version, sans le correctif du 12 octobre, quand un compte fraîchement enregistré a commencé à le sonder le 20 octobre.
Ce compte a envoyé des configurations CI forgées les 20 et 21 octobre. Elles ont fait planter les processus worker de GitLab à huit reprises. L’attaque principale, le 21 octobre, a provoqué des erreurs 502 et l’échec de jobs CI. Dans quatre de ces crashs, l’attaquant a progressé partiellement dans la chaîne d’exploitation avant d’échouer à l’étape suivante. Détail révélateur : l’attaquant a téléchargé l’image conteneur GitLab d’Alpine, ce qui, selon le projet, « suggère qu’il réglait l’exploit sur notre build exact ».
Le compte a été bloqué le 23 octobre, puis l’attaquant a tenté de revenir les 25 et 26 octobre, sans succès. Le 26 octobre, Alpine a découvert que le serveur était toujours vulnérable malgré la mise à niveau du 22. Le lendemain, il a fermé GitLab à tous sauf à ses développeurs et à ses serveurs de build, et a commencé la reconstruction. Elle s’est achevée le 28 octobre, avec de nouvelles clés secrètes et un serveur sous Ruby 3.3.13 ou plus récent.
Ce qu’Alpine peut et ne peut pas écarter
Alpine n’a trouvé aucun signe que le code de l’attaquant s’est exécuté : pas de délai anormal dans les sondes de synchronisation, pas de fichier, de clé, de hook ou de processus inattendu, pas d’exfiltration visible dans les requêtes web ou API. Mais le projet refuse d’en conclure quoi que ce soit. « Un exploit réussi ne laisserait ni crash ni trace dans les journaux web », écrit-il. Certains journaux du jour de l’attaque ont disparu, ni Alpine ni son hébergeur ne journalisaient les connexions réseau sortantes, et le système de fichiers de l’ancien conteneur n’existe plus.
Faute de preuve, Alpine a donc traité le serveur comme compromis et l’a reconstruit pour supprimer toute persistance qu’un exploit réussi aurait pu laisser. Si l’attaque avait abouti, voici ce qui aurait pu être exposé : les adresses e-mail, noms et adresses IP de tous les utilisateurs, les empreintes de mots de passe, les secrets 2FA, les variables CI/CD et les jetons de runner, les identifiants de webhooks, d’intégrations et de miroirs de push, les jetons d’accès personnel (stockés sous forme de hachage), ainsi que les dépôts privés et les issues et merge requests confidentielles.
La réponse ne s’arrête pas au correctif logiciel. Alpine a confirmé que chaque modification d’aports ajoutée du 20 au 22 octobre provenait d’un push enregistré par un développeur connu, en recoupant avec des enregistrements que l’attaquant ne pouvait pas atteindre : la copie du dépôt d’un développeur et les 45 serveurs de build. Les paquets construits du 20 au 24 octobre proviennent tous de modifications d’aports conformes à ce qui est publié sur git.alpinelinux.org. Les clés qui signent les paquets et les versions n’ont, elles, jamais été sur le serveur GitLab.
La racine technique : Onigmo, pas GitLab
Pourquoi la mise à niveau de GitLab ne corrigeait-elle rien ? Parce que le bug derrière la CVE-2026-97229 vit dans Onigmo, le moteur d’expressions régulières intégré à Ruby. GitLab compile les expressions régulières des configurations CI avec Ruby ; son correctif du 12 octobre a donc patché le Ruby embarqué dans ses paquets et images. Les versions corrigées de Ruby lui-même ne sont sorties que les 22 et 23 octobre. Une mise à niveau de GitLab ne change pas le Ruby du serveur hôte : une installation sur Ruby standard conserve la faille tant que Ruby n’est pas mis à jour.
Le reproche d’Alpine est documenté et mérite l’attention des administrateurs : au 29 octobre, aucun des billets de correctif de GitLab (12 et 21 octobre) n’indiquait aux installations auto-compilées de mettre à jour Ruby. Le guide d’installation auto-compilée liste encore Ruby 3.2 comme version minimale — or Ruby 3.2 est en fin de vie depuis avril et ne recevra aucun correctif. C’est un angle mort de documentation qui transforme une faille corrigée en faille toujours ouverte pour une minorité silencieuse de déploiements.
Qui est réellement exposé
GitLab.com et GitLab Dedicated sont corrigés. Rapid7 a construit un exploit fonctionnel en laboratoire et publié un proof of concept le 13 octobre : il exécute des commandes en tant qu’utilisateur git sur une image GitLab 19.4.1 non patchée, mais pas sur l’image 19.4.2 patchée. Cet exploit suppose un accès en écriture préalable — committer un fichier .gitlab-ci.yml malveillant et un chemin en UTF-8 sur une branche d’un projet public — une condition qui disparaît sur les serveurs où l’inscription libre permet de créer ses propres projets. La CVE-2026-97229 n’était toujours pas au catalogue KEV de la CISA au 28 octobre, ce qui signifie qu’elle n’est pas (encore) officiellement reconnue comme exploitée par des campagnes suivies.
# Installations GitLab sur Ruby maison : vérifier la version de Ruby, pas seulement GitLab
ruby --version
# Le correctif exige Ruby 3.3.13, 3.4.12 ou 4.0.9 (ou plus récent)
# Puis mettre à niveau GitLab vers la branche corrigée (ex. 19.3.6, 19.4.3, 19.5.1)Verdict
Si vous hébergez GitLab sur un Ruby compilé vous-même ou une image conteneur maison, vérifiez votre version de Ruby dès aujourd’hui : « mettre à niveau GitLab ne suffit pas », et la fenêtre n’est pas théorique — un attaquant a déjà tenté l’exploitation contre l’infrastructure d’un projet aussi rigoureux qu’Alpine Linux. Si vous maintenez une distribution ou un dépôt de paquets, copiez la méthode Alpine : conservez vos clés de signature hors du serveur de forge et recoupez la provenance de vos paquets avec des enregistrements hors bande que l’attaquant ne peut pas atteindre. Et si vous êtes un simple utilisateur d’images Alpine ou de tout autre distro, la bonne nouvelle est banale : les clés de signature n’étaient pas exposées, et les versions officielles restent intègres — la leçon est pour les mainteneurs, pas pour les consommateurs de paquets. Cet incident restera comme le rappel que la sécurité d’une supply chain ne tient pas au correctif que l’on applique, mais à celui que l’on pense avoir appliqué.