Alpine Linux reconstruit GitLab après une tentative d'exploitation critique via une faille regex de Ruby

Les 20 et 21 octobre, un attaquant a ciblé l'instance GitLab d'Alpine Linux en exploitant une vulnérabilité critique dans le moteur d'expressions régulières de Ruby. Bien qu'il n'y ait aucune preuve d'exécution de code réussie, l'équipe n'a pas pu l'exclure et a choisi de reconstruire entièrement le service depuis zéro pour garantir son intégrité.

Ce qui s'est passé

L'incident tourne autour de la CVE-2026-97229, une faille critique avec un score CVSS de 10.0 affectant la manière dont GitLab évalue les expressions régulières dans les fichiers de configuration CI. La cause racine se trouve dans Onigmo, le moteur d'expressions régulières intégré à Ruby. GitLab a publié des versions corrigées le 12 octobre, mais ces correctifs nécessitaient des patchs spécifiques sur le runtime Ruby inclus plutôt que des modifications du code applicatif de GitLab lui-même. Alpine Linux a par erreur effectué une mise à niveau vers GitLab 19.3.4 au lieu de la version corrigée 19.3.5 le 13 octobre, laissant leur instance exposée.

Entre le 20 et le 21 octobre, un compte nouvellement enregistré a soumis des configurations CI élaborées conçues pour déclencher la vulnérabilité. Ces charges utiles ont fait planter les processus workers de GitLab huit fois. Dans quatre de ces cas, l'attaquant a avancé partiellement dans la chaîne d'exploitation avant d'échouer à l'étape suivante. L'attaquant a également téléchargé l'image conteneur GitLab, probablement pour affiner l'exploit contre l'environnement de build spécifique. Bien que l'équipe n'ait observé aucun signe d'exécution de code réussie, comme des fichiers inattendus ou des retards de processus, elle a reconnu qu'une exploitation réussie ne laisserait aucune trace dans les logs web standards.

Pour compliquer la réponse, une mise à niveau vers GitLab 19.3.6 le 22 octobre n'a pas résolu la vulnérabilité. Parce que l'image conteneur d'Alpine utilisait Ruby standard plutôt que le bundle corrigé de GitLab, la faille sous-jacente est restée présente jusqu'à ce que Ruby publie lui-même le correctif dans les versions 3.3.13, 3.4.12 et 4.0.9 le 23 octobre. Une fois que l'équipe a réalisé que son instance était toujours vulnérable le 26 octobre, elle a fermé l'accès à tous sauf aux développeurs et a lancé une reconstruction complète.

Comment cela fonctionne

Cette vulnérabilité exploite la façon dont les expressions régulières sont traitées par le moteur Onigmo au sein de Ruby. Lorsque GitLab analyse les fichiers de configuration CI, il compile ces expressions régulières. Si un attaquant fournit un motif malveillant, cela peut provoquer un comportement imprévisible du moteur, permettant potentiellement une exécution de code à distance. Il ne s'agit pas d'une faille dans la logique métier de GitLab, mais dans le runtime du langage fondamental dont il dépend.

Pour les instances auto-hébergées, cela crée une chaîne de dépendances complexe. Mettre simplement à jour l'application GitLab est insuffisant si l'environnement hôte utilise une installation Ruby système non corrigée. Les packages officiels de GitLab incluent un Ruby corrigé, mais les déploiements personnalisés ou les images conteneurs qui reposent sur le Ruby upstream doivent attendre que les mainteneurs du langage publient le correctif. Dans ce cas, le correctif est arrivé dans les releases Ruby le 23 octobre, plus d'une semaine après le premier patch de GitLab.

Détails clés

• Vulnérabilité : CVE-2026-97229 (CVSS 10.0) dans le moteur regex Onigmo de Ruby.
• Fenêtre d'attaque : 20–21 octobre, avec de nouvelles tentatives les 25–26 octobre.
• Impact : Huit plantages de workers ; aucune violation de données confirmée, mais traitée comme compromise.
• Échec de mitigation : La mise à niveau de GitLab vers 19.3.6 n'a pas corrigé le problème car le Ruby sous-jacent n'était pas patché.
• Vérification : Les releases et packages Alpine des 20–24 octobre ont été vérifiés contre des registres externes et jugés intacts.
• Réponse : Reconstruction complète de l'instance, réinitialisation des mots de passe et implémentation de la journalisation des connexions sortantes.

Pourquoi c'est important

Cet incident met en évidence un angle mort critique dans la gestion des infrastructures auto-hébergées : la distinction entre les patches au niveau application et les correctifs au niveau runtime. Les développeurs supposent souvent que la mise à niveau du package logiciel principal résout tous les risques de sécurité associés. Cependant, lorsque des vulnérabilités existent dans des dépendances partagées comme Ruby, Python ou Node.js, le chemin de remédiation est fragmenté. Les équipes doivent suivre les patches à travers plusieurs couches, y compris le runtime du langage, les packages du système d'exploitation et l'application elle-même.

Pour les responsables d'ingénierie, cela souligne l'importance de vérifier la composition des images conteneurs et des artefacts de déploiement. Se reposer sur les packages système par défaut peut introduire un décalage entre le correctif d'un fournisseur et la posture de sécurité de votre environnement. De plus, l'absence de journalisation réseau sortante a entravé l'enquête, démontrant que la visibilité sur le trafic egress est tout aussi vitale que la surveillance ingress pour détecter l'exfiltration ou l'activité de command-and-control.

Ce que vous pouvez faire

• Vérifiez immédiatement votre version de Ruby ; assurez-vous d'utiliser 3.3.13, 3.4.12, 4.0.9 ou une version ultérieure si vous utilisez GitLab.
• Vérifiez vos images conteneurs GitLab ; si vous avez extrait alpinelinux/gitlab:19.3.6 avant le 27 octobre, extrayez-le à nouveau pour obtenir le Ruby corrigé.
• Auditez vos pipelines CI/CD pour toute modification récente ou jobs échoués pouvant indiquer des tentatives de sondage.
• Activez la journalisation des connexions réseau sortantes depuis vos serveurs CI et hôtes de base de données pour améliorer les capacités de réponse aux incidents.
• Réinitialisez tous les mots de passe et faites pivoter les secrets, y compris les variables CI/CD et les jetons runner, si vous suspectez une exposition.
• Implémentez des tags de release signés pour vos artefacts internes afin de permettre une vérification indépendante de l'intégrité des builds.