Alpine Linux subit une tentative d'exploitation CVE-2026-97229 sur GitLab
Sommaire
En bref
- Alpine Linux a subi une tentative d'exploitation d'une faille GitLab critique (CVE-2026-97229) les 20 et 21 octobre, environ une semaine après la publication du correctif.
- Le correctif réside dans Ruby, pas dans le code GitLab lui-même, ce qui a laissé les instances utilisant une Ruby standard vulnérables malgré la mise à niveau de GitLab.
- Alpine a reconstruit son instance GitLab par précaution, ne trouvant pas de preuve d'exécution de code, mais sans pouvoir exclure un succès partiel de l'attaque.
- Tous les utilisateurs d'Alpine doivent réinitialiser leur mot de passe et mettre à jour Ruby vers les versions 3.3.13, 3.4.12 ou 4.0.9+.
Ce que dit la source
Alpine Linux rapporte qu'un attaquant a tenté d'exploiter CVE-2026-97229, une faille critique (CVSS 10.0) affectant l'évaluation des expressions régulières dans les configurations CI de GitLab. L'équipe Alpine a découvert que GitLab a publié des correctifs le 12 octobre, mais le correctif lui-même consiste en des patchs appliqués uniquement aux paquets et images officiels de GitLab, tandis que la Ruby en amont ne l'a reçu que le 23 octobre. Alpine a par erreur upgrader vers la version 19.3.4 au lieu de 19.3.5 (qui contenait le correctif), ce qui a laissé l'instance vulnérable. L'attaquant a créé un compte le 20 octobre et envoyé des configurations CI malveillantes les 20 et 21 octobre, causant 8 plantages du worker GitLab, dont 4 où l'attaque a partiellement fonctionné avant d'échouer à l'étape suivante.
- L'attaquant a téléchargé l'image GitLab d'Alpine, suggérant une adaptation de l'exploit à la configuration spécifique
- Aucune preuve que du code a été exécuté sur le serveur n'a été trouvée, mais Alpine ne peut pas l'exclure complètement
- La faille réside dans Onigmo, le moteur regex intégré à Ruby, pas dans le code GitLab lui-même
- Alpine a reconstruit l'instance complète par prudence plutôt que de simplement mitiguer l'attaque
- Les paquets Alpine et les releases d'octobre 21 n'ont pas été modifiés ; chaque commit aports a été vérifié contre des enregistrements inaccessibles à l'attaquant
- Si la mise à niveau de GitLab seule ne suffit pas, les utilisateurs qui compilent à partir des sources ou utilisent leur propre Ruby doivent aussi mettre à jour Ruby
- Alpine utilise une image GitLab avec Ruby standard, pas les paquets officiels GitLab qui incluent le correctif
Dans les commentaires
Débat partagé sur les implications plus larges : reconnaissance de la rigueur d'Alpine, mais critique légitime sur la chaîne d'approvisionnement logicielle et l'effort requis pour maintenir à jour les builds custom.
- Plusieurs commentateurs soulignent que le vrai problème est structural : ceux qui compilent à partir des sources ou créent leurs propres images doivent monitorer deux niveaux de correctifs (GitLab ET Ruby) plutôt qu'un seul, ce qui explique pourquoi Alpine n'a pas reçu le correctif.
- Un commentateur conteste le titre comme trompeur : "attempted" suggère l'échec, alors que le rapport indique une attaque potentiellement partielle ou complète.
- La question du versioning des images est signalée : re-publier une 19.3.6 corrigée sans nouveau tag de version rend difficile la détection du problème pour les outils de scanning, qui verront 19.3.6 comme "fixed" selon l'avis CVE.
- Un argument minoritaire mais fondé : Alpine pourrait envisager un fork maintenu comme Forgejo plutôt que GitLab, étant donné la surface d'attaque et la complexité de la maintenance.
- Absence de clarté sur quelles versions non supportées de Ruby restent affectées sans correctif de sécurité disponible.
Notre lecture
Alpine a géré l'incident avec transparence et prudence. Le vrai signal, cependant, est structural : la faille expose les risques quand un correctif critique réside dans une dépendance système (Ruby) plutôt que dans le logiciel exposé (GitLab), et que les builds custom héritent cette complexité sans bénéficier de la synchronisation des paquets officiels. Pour toute organisation qui compile GitLab ou d'autres outils à partir des sources, ce scénario devient un cas d'école d'une chaîne de dépendances fragile. À surveiller pour les DSI qui maintiennent des instances custom : la leçon clé est que "mise à jour du logiciel = sécurisé" n'est plus vrai quand le correctif vit en amont.