GitLab CVE-2026-97229 : Alpine signale une tentative d'exploitation

Alpine Linux indique qu'un attaquant a tenté d'exploiter CVE-2026-97229 sur le serveur GitLab du projet les 20 et 21 octobre 2026. C'était environ une semaine après la publication d'un correctif par GitLab. La leçon la plus importante se trouve dans le rapport d'incident d'Alpine, publié le 28 octobre. Mettre à jour GitLab lui-même n'a pas comblé la faille dans la configuration d'Alpine, car le vrai correctif est un patch de Ruby.

Alpine est une petite distribution Linux très populaire comme base pour les conteneurs Docker. Ses développeurs utilisent un serveur GitLab auto-hébergé pour gérer le code de ses paquets.

Ce qui s'est passé sur le serveur d'Alpine

Selon Alpine, les tentatives ont fait planter les processus workers de GitLab huit fois. Lors de quatre de ces plantages, l'attaquant a avancé en partie dans l'exploit.

Alpine dit n'avoir trouvé aucune preuve que l'attaque ait fonctionné. « Nous n'avons trouvé aucune preuve qu'elle ait réussi, mais nous ne pouvons pas l'exclure », indique le billet.

L'équipe a donc traité le serveur comme compromis. Elle a reconstruit GitLab de zéro et limité l'accès aux développeurs et aux serveurs de build. Elle a aussi réinitialisé tous les mots de passe et toutes les clés secrètes.

Le projet a aussi vérifié ce qui compte le plus pour ses utilisateurs. Selon Alpine, son dépôt aports, ses paquets et ses versions stables du 21 octobre ont été comparés à des enregistrements externes. Ils ne montraient aucun signe de falsification. Ces versions étaient Alpine 3.21.9, 3.22.7, 3.23.7 et 3.24.3. Les clés qui signent les paquets Alpine n'ont jamais été stockées sur le serveur GitLab, et 45 machines de build ont été vérifiées.

Alpine a trouvé un autre problème au passage. Des connexions automatisées sur son serveur utilisaient des mots de passe ayant fuité d'autres sites web. Toute personne ayant réutilisé son mot de passe Alpine GitLab ailleurs devrait le changer là-bas.

Pourquoi la mise à jour de GitLab n'a pas aidé

C'est la partie que les autres auto-hébergeurs devraient lire deux fois. « La mise à jour vers GitLab 19.3.6 le 22 octobre n'a pas corrigé la vulnérabilité », écrit Alpine.

La raison tient à la façon dont GitLab livre le correctif. Les paquets officiels de GitLab embarquent leur propre copie de Ruby, le langage de programmation dans lequel GitLab est écrit. Selon Alpine, le correctif de CVE-2026-97229 est un ensemble de patchs pour ce Ruby embarqué. Alpine fait tourner GitLab sur un Ruby standard, si bien qu'une version plus récente de GitLab ne changeait rien à elle seule.

Alpine indique aussi avoir sauté par erreur la mise à jour 19.3.5 le 13 octobre. Pendant l'attaque, le serveur tournait encore sous 19.3.4. Les propres paquets ruby d'Alpine incluent désormais le correctif, et les utilisateurs d'Alpine doivent lancer apk upgrade.

Qu'est-ce que CVE-2026-97229

GitLab a divulgué la faille le 12 octobre 2026 et a pressé toutes les installations autogérées de se mettre à jour. BleepingComputer a rapporté qu'il s'agit d'un dépassement d'entier dans la partie de GitLab qui lit les expressions régulières des fichiers de pipeline CI/CD. Les expressions régulières sont des motifs de texte, et les pipelines CI/CD sont les scripts qui compilent et testent le code automatiquement. L'avis de GitLab indiquait que le bug « aurait pu permettre à un utilisateur non authentifié d'exécuter du code arbitraire sur le serveur GitLab ».

Un chercheur utilisant le pseudonyme « joaxcar » l'a signalée via le programme de bug bounty de GitLab sur HackerOne. GitLab.com était déjà corrigé, et les clients de GitLab Dedicated n'avaient rien à faire.

Élément	Détail
Gravité	CVSS 10.0, le maximum
Type de bug	Dépassement d'entier dans le compilateur de regex CI/CD
Versions corrigées	19.2.8, 19.3.4 ou 19.3.5, et 19.4.2 (les sources divergent sur la 19.3)
Exploit public	Publié par Rapid7 le 13 octobre
Hôtes exposés	25 766 sur des versions vulnérables, selon Censys

Les sources ne s'accordent pas sur le correctif de la 19.3. BleepingComputer indique 19.3.4. Daily Security Review et Alpine renvoient tous deux à 19.3.5. Consultez l'avis de GitLab lui-même pour votre branche exacte.

Daily Security Review a rapporté le 14 octobre que l'exploit repose sur un fichier piégé commité dans une branche d'un projet public. À ce moment-là, aucune attaque réelle n'était confirmée. L'agence américaine de cybersécurité et de sécurité des infrastructures (CISA) n'avait pas non plus ajouté le bug à sa liste de failles exploitées. Censys a aussi constaté qu'environ 31 % des hôtes GitLab détectés n'étaient toujours pas corrigés.

C'est la deuxième faille regex de gravité maximale chez GitLab ce mois-ci. GitLab 19.5.1 a corrigé CVE-2026-110264, un bug distinct noté CVSS 10.0, le 21 octobre.

Ce que cela signifie pour les développeurs

Le rapport d'Alpine transforme un correctif connu en liste de contrôle concrète. Il montre aussi que « nous avons mis à jour » et « nous sommes en sécurité » ne sont pas la même chose.

• Vérifiez d'où votre GitLab tire son Ruby. Si vous faites tourner GitLab depuis les sources ou depuis les paquets d'une distribution sur le Ruby du système, la mise à jour de GitLab seule peut ne pas apporter le correctif. Confirmez que votre Ruby inclut les patchs, comme Alpine a dû le faire.
• Ne sautez pas les versions correctives. Alpine a manqué la 19.3.5 par erreur. Calez votre processus de mise à jour sur les avis de sécurité de GitLab, pas sur un calendrier de routine.
• Partez du principe qu'un serveur public a été sondé. Un exploit public existe depuis le 13 octobre. Si vous avez fait tourner une version vulnérable sur Internet après cette date, examinez les journaux de plantage des workers des semaines suivantes.
• Verrouillez les projets publics. L'exploit a besoin d'un fichier piégé dans un projet public. Tant que vous n'avez pas appliqué le correctif, limitez qui peut atteindre le serveur et désactivez la création de projets publics pour les utilisateurs non fiables.
• Gardez les clés de signature hors de la forge. Alpine a pu affirmer que ses paquets étaient sûrs parce que les clés de signature n'ont jamais résidé sur GitLab. Ce choix de conception mérite d'être copié.
• Réinitialisez les mots de passe réutilisés. Des connexions par credential stuffing sont aussi apparues chez Alpine. Poussez les utilisateurs vers des mots de passe uniques et la connexion à deux facteurs jusqu'à ce qu'ils soient en place partout.