GitLab : CVSS 10, du code exécuté sans compte

Ce qui se passe

GitLab a publié le 12 octobre les versions 19.4.2, 19.3.5 et 19.2.8, pour les éditions Community et Enterprise. Elles corrigent CVE-2026-97229, notée CVSS 10,0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H : réseau, sans privilège, sans interaction). Dans certaines conditions, un utilisateur non authentifié pouvait faire exécuter du code arbitraire au serveur GitLab avec une expression régulière forgée dans une configuration CI/CD, faute de validation suffisante. L'avis la classe comme un dépassement d'entier dans le compilateur d'expressions régulières de la CI/CD ; elle a été signalée par joaxcar via HackerOne.

Pourquoi ça compte

Un serveur GitLab détient le code de tous les projets, les jetons et les variables de CI : l'exécuter, c'est tenir toute la chaîne de livraison. C'est la suite des deux failles de regex corrigées le 23 septembre (CVE-2026-89078 et CVE-2026-93577, CVSS 9,9, comptes authentifiés), et la précédente faille notée 10,0 (CVE-2026-85706, lecture de fichiers) avait été sondée dans les heures suivant sa publication, selon The Hacker News. L'avis ne dit pas si CVE-2026-97229 est déjà exploitée.

Versions

• Touchées : 19.2 avant 19.2.8 ; 19.3 avant 19.3.5 ; 19.4 avant 19.4.2.
• Corrigées : 19.4.2, 19.3.5, 19.2.8. GitLab.com est déjà à jour ; les clients Dedicated n'ont rien à faire.
• La 19.3.4 avait un bug sur les pages de merge request quand l'intégration Ona était activée : il est corrigé en 19.3.5.

Les failles hautes du même lot

• CVE-2026-92883 (8,7) : XSS dans la coloration syntaxique, via un dépôt forgé, pour un utilisateur authentifié.
• CVE-2026-16301 (8,5) : un rôle Developer pouvait lancer des pipelines sur des branches protégées par le service de création de pipelines aval.
• CVE-2026-14814 (8,2) : regex permissive sur l'accès aux fichiers du dépôt, qui permettait d'empoisonner le cache des fichiers bruts et d'exposer des variables protégées dans les pipelines des utilisateurs visés.

L'avis en liste d'autres, de gravité moyenne ou basse.

Comment s'y prendre

• Instance auto-hébergée en 19.2, 19.3 ou 19.4 : passer dans la branche corrigée sans attendre la fenêtre de maintenance habituelle.
• Relire les pipelines lancés sur des branches protégées depuis un rôle Developer si l'instance était exposée.

Source : GitLab Patch Release: 19.4.2, 19.3.5, 19.2.8, GitLab, 12 octobre 2026. Contexte : The Hacker News, 13 octobre 2026.