GitLab et Alpine Linux : pourquoi une mise à jour n’a pas suffi

Une faille critique dans le traitement des configurations CI

La vulnérabilité CVE-2026-97229 concerne l’évaluation d’expressions régulières dans les configurations CI/CD GitLab. Elle peut, dans certaines conditions, conduire à l’exécution de code à distance. GitLab a publié des versions corrigées le 12 octobre 2026. Les branches affectées comprennent GitLab 19.2 avant 19.2.8, 19.3 avant 19.3.5 et 19.4 avant 19.4.2. Ces seuils ne remplacent pas la vérification du dernier correctif disponible.

Ce qui s’est passé chez Alpine Linux

Alpine rapporte des tentatives d’exploitation les 20 et 21 octobre. Un compte nouvellement créé a soumis des configurations CI conçues pour déclencher la faille. Plusieurs processus de travail ont planté. Alpine n’a trouvé aucune preuve d’exécution de code réussie, mais ne pouvait pas l’exclure, notamment en raison de journaux incomplets.

Par précaution, le projet a reconstruit son serveur GitLab, remplacé des secrets et réinitialisé les mots de passe. Il indique n’avoir constaté aucune altération des paquets et des versions Alpine examinés.

Pourquoi la mise à jour GitLab n’a pas suffi

Le défaut se trouve dans Onigmo, moteur d’expressions régulières de Ruby. Les paquets et images officiels GitLab incluaient un correctif Ruby spécifique. Mais Alpine utilisait une image personnalisée avec Ruby standard : même après son passage à GitLab 19.3.6 le 22 octobre, le composant vulnérable était toujours présent.

Les versions amont corrigées de Ruby comprennent 3.3.13, 3.4.12 et 4.0.9. Alpine indique avoir republié son image alpinelinux/gitlab:19.3.6 le 27 octobre avec Ruby corrigé : une image de même étiquette récupérée auparavant pouvait encore être vulnérable.

Ce que doivent vérifier les équipes

Identifier la provenance du déploiement : paquet officiel GitLab, image officielle, image communautaire ou installation depuis les sources.
Contrôler la version effective de Ruby : pour une installation utilisant le Ruby système ou une image personnalisée, vérifier la version et les correctifs du moteur, indépendamment de celle de GitLab.
Reconstruire et redéployer les images : ne pas déduire l’état de sécurité du seul tag ; privilégier les images corrigées et des références immuables par digest.
Vérifier les accès : limiter les comptes et droits permettant de soumettre des configurations CI non fiables ; appliquer les correctifs éditeur.
Préserver les preuves : en cas de soupçon d’exploitation, conserver les journaux et envisager une réponse à incident plutôt qu’une simple mise à jour.
Contrôler la chaîne de construction : inventorier les bibliothèques du runtime et tester les images réellement exécutées, y compris celles construites en interne.

Leçon pour les infrastructures conteneurisées

Le numéro de version de l’application n’est pas une preuve que toutes ses dépendances sont corrigées. Les équipes doivent examiner le système de base, le runtime, les bibliothèques et les images effectivement déployées. Ce principe s’applique au-delà de GitLab, notamment aux services Docker construits à partir d’images maison.

La Veille logiciels TechAtelier aide à suivre les versions logicielles ; elle ne remplace pas l’analyse des dépendances d’une image ni la réponse à incident.

Sources officielles

Publié le 31 octobre 2026.