GitLab auto-hébergé : patchez aussi Ruby

Ce qui se passe

Alpine Linux a publié le 28 octobre le post-mortem d'un incident sur son instance GitLab. Les 20 et 21 octobre, un compte fraîchement créé a envoyé des configurations d'intégration continue forgées à gitlab.alpinelinux.org, encore en version 19.3.4. Résultat : huit plantages de processus worker, dont quatre où l'attaquant est allé une étape plus loin avant d'échouer. Il avait aussi téléchargé l'image conteneur du projet, signe qu'il ajustait son attaque à ce build précis.

Rien ne prouve que du code a été exécuté sur le serveur. Rien ne l'exclut non plus. L'équipe a donc traité l'instance comme compromise et l'a reconstruite de zéro, avec réinitialisation de tous les mots de passe et remplacement des clés secrètes de GitLab.

Le piège : mettre à jour GitLab ne suffit pas

CVE-2026-97229 est une faille critique (CVSS 10.0) dans l'évaluation des expressions régulières de la configuration CI. Mais le bug est en réalité dans Onigmo, le moteur d'expressions régulières de Ruby (notre fiche du 24 octobre).

GitLab a publié ses versions corrigées le 12 octobre. Or le correctif consiste en un jeu de rustines appliquées au Ruby que GitLab embarque dans ses propres paquets et images. Alpine est passé en 19.3.6 le 22 octobre avec un Ruby standard : l'instance est restée vulnérable, ce qui n'a été découvert que le 26 octobre.

Deux chemins de mise à jour, un seul qui corrige la faille

Ruby a publié le correctif en amont le 23 octobre, dans 3.3.13, 3.4.12 et 4.0.9.

Ce que ça change pour vous

Si vous installez GitLab depuis les paquets ou images officiels, la mise à jour de GitLab suffit.
Si vous le compilez depuis les sources ou construisez votre propre image avec votre Ruby, il faut en plus Ruby 3.3.13, 3.4.12 ou 4.0.9 ou plus récent.
Si vous utilisez l'image alpinelinux/gitlab, retéléchargez alpinelinux/gitlab:19.3.6 : celle publiée le 27 octobre contient Ruby 3.3.13. Toute image 19.3.6 récupérée avant cette date, et tous les tags plus anciens, sont vulnérables.
Le bug n'est pas propre à GitLab : tout programme qui compile une expression régulière issue d'une entrée non fiable est concerné. Alpine 3.22, 3.23, 3.24 et edge livrent Ruby 3.4.12, Alpine 3.21 livre 3.3.13 ; un apk upgrade suffit.

Ce qui a été vérifié, et ce qui reste incertain

Vérifié intact : les publications stables du 21 octobre — 3.21.9, 3.22.7, 3.23.7, 3.24.3 —, leurs images ISO, les tarballs minirootfs dont sont bâties les images Docker officielles alpine, et tous les paquets construits du 20 au 24 octobre. Les commits d'aports ont été recoupés contre des sources hors d'atteinte de l'attaquant : le clone d'un développeur et les 45 serveurs de compilation. Les clés de signature n'ont jamais été stockées sur le serveur GitLab.

Incertain : un exploit réussi n'aurait laissé ni plantage ni trace dans les journaux web ; certains journaux du jour de l'attaque ont disparu, et aucune journalisation des connexions sortantes n'existait. En cas de succès, auraient pu être exposés : adresses de courriel, noms et adresses IP de tous les utilisateurs, empreintes de mots de passe, secrets 2FA, variables CI/CD, jetons de runner, identifiants de webhooks et d'intégrations, jetons d'accès personnels (sous forme d'empreintes), dépôts privés et tickets confidentiels.

Détail qui compte : le 13 octobre, à la publication de la CVE, l'équipe a mis à jour en 19.3.4 au lieu de 19.3.5, qui portait le correctif — une erreur, pas un oubli de mise à jour.

Mesures annoncées par le projet : appliquer les correctifs critiques de GitLab sous un jour, vérifier à chaque version si des composants comme Ruby exigent une rustine propre à leur build, journaliser les connexions sortantes, conserver les journaux plus de 14 jours, et signer les tags de publication pour qu'ils soient vérifiables indépendamment de GitLab.

Source : alpinelinux.org, 28 octobre 2026. Source en anglais.