Faille GitLab CVE-2026-97229 : Alpine Linux reconstruit sa forge après une attaque

Le 28 octobre 2026, le projet Alpine Linux a détaillé dans un billet une attaque contre sa forge logicielle GitLab, l’outil qui héberge son code et automatise ses tests. Les 20 et 21 octobre, un compte fraîchement créé y a soumis des configurations piégées d’intégration continue (CI), le mécanisme qui lance ces tests. Cible : la faille GitLab CVE-2026-97229, notée 10,0 sur l’échelle de gravité CVSS, soit le maximum. Faute de pouvoir exclure un succès de l’attaquant, le projet a reconstruit son serveur de zéro.

Une faille corrigée le 12 octobre

GitLab a publié les correctifs le 12 octobre 2026. Selon l’éditeur, un utilisateur pouvait, sans même s’identifier, exécuter le code de son choix sur le serveur. Il passait par une expression régulière piégée (un motif de recherche dans un texte), glissée dans une configuration CI/CD. L'avis de GitLab liste les versions touchées : la 19.2 avant la 19.2.8, la 19.3 avant la 19.3.5 et la 19.4 avant la 19.4.2. L’éditeur recommande fortement de mettre à niveau toutes les installations auto-hébergées concernées ; BleepingComputer a relayé l’alerte le jour même.

Les sources divergent sur la branche 19.3. BleepingComputer cite la 19.3.4 comme première version corrigée ; GitLab et IT-Connect indiquent la 19.3.5. Le récit d’Alpine va dans leur sens : le projet a installé par erreur la 19.3.4 au lieu de la 19.3.5, qui contenait le correctif. Nous retenons la 19.3.5, version donnée par l’éditeur lui-même.

Le Ruby embarqué, angle mort

Alpine souligne une particularité : le correctif modifie le Ruby, un langage de programmation, que GitLab embarque dans ses propres paquets et images de conteneurs. L’image maison d’Alpine reposait sur un Ruby standard : passer à GitLab 19.3.6, le 22 octobre, n’a donc pas suffi. Qui fait tourner GitLab avec son propre Ruby doit aussi installer Ruby 3.3.13, 3.4.12, 4.0.9 ou une version ultérieure. Ruby les a publiées dans son annonce du 23 octobre 2026. Elles corrigent des bugs de son moteur d’expressions régulières, Onigmo, repérés par GitLab.

Une instance reconstruite de zéro

Les envois de l’attaquant ont fait planter 8 fois les processus qui font tourner GitLab. L’équipe a traité l’instance comme compromise. Le 27 octobre, elle l’a fermée à tous, sauf aux développeurs et aux serveurs de compilation, puis a commencé à la rebâtir. Faute du bon Ruby, son GitLab était resté vulnérable jusqu’à cette fermeture.

Selon Alpine, les paquets et les versions du projet n’ont pas été modifiés, et les clés qui les signent n’ont jamais été stockées sur le serveur GitLab. Le doute demeure pourtant : le projet ne journalisait pas les connexions sortantes de son serveur, et son hébergeur non plus. Une attaque réussie aurait pu exposer des secrets de double authentification (2FA), des variables CI/CD et des jetons de runners, ces agents qui exécutent les tâches automatiques. Le site spécialisé Security Online a relayé ce récit ; à notre connaissance, aucune vérification extérieure n’a été publiée.

Nous n’avons trouvé aucune preuve que l’attaque ait réussi, mais nous ne pouvons pas l’exclure.

Alpine en tire des consignes. Les utilisateurs de son image de conteneur doivent récupérer à nouveau alpinelinux/gitlab:19.3.6 : la version publiée le 27 octobre contient Ruby 3.3.13. Le projet s’engage aussi à appliquer les correctifs de sécurité critiques de GitLab en moins d’une journée. Nous en retenons qu’un numéro de version ne prouve rien à lui seul : un correctif ne protège que s’il est réellement présent, jusque dans les composants embarqués.

La leçon vaut, à notre avis, pour toute TPE, association ou collectivité qui héberge son propre GitLab. Les projets confiés à GitLab.com n’ont rien à faire : le service tourne déjà sous la version corrigée. Ailleurs, vérifiez d’abord la version installée : 19.2.8, 19.3.5 ou 19.4.2 au minimum, selon votre branche. Si vous n’utilisez ni les paquets ni les images officiels de l’éditeur, contrôlez aussi le Ruby. Limitez la création de comptes, conservez des journaux, y compris des connexions sortantes, et gardez des sauvegardes pour pouvoir tout reconstruire. Dans la mesure de nos disponibilités, nous aidons ponctuellement, bénévolement et gratuitement, à contrôler une installation.