Ing. Calogero Bono
Le 12 octobre 2026, GitLab a publié les versions 19.4.2, 19.3.5 et 19.2.8 pour Community Edition et Enterprise Edition. Elles contiennent la correction de CVE-2026-97229, une faille notée CVSS 10.0 qui peut mener à l'exécution de code arbitraire sur le serveur. Jeudi, la CISA américaine a confirmé une exploitation active et a ajouté la faille à son catalogue KEV. Si tu gères une instance GitLab toi-même, la priorité est de mettre à jour immédiatement.
Quelques termes avant d'entrer dans les faits. CVE est le code qui identifie une vulnérabilité publique. CVSS est le score de gravité de 0 à 10. CI/CD désigne les pipelines automatiques qui compilent, testent et publient le code. KEV est le catalogue de la CISA recensant les failles déjà exploitées dans des attaques réelles. RCE signifie exécution de code à distance, c'est-à-dire lancer des commandes sur le serveur d'un autre.
Qu'est-ce que CVE-2026-97229 ?
Selon la page officielle de GitLab, il s'agit d'un problème de dépassement d'entier (integer overflow) dans le compilateur d'expressions régulières utilisé pour les configurations CI/CD. Dans certaines conditions, un utilisateur non authentifié pouvait exécuter du code arbitraire sur le serveur à l'aide d'une expression régulière spécialement construite, à cause d'une validation insuffisante.
Le vecteur CVSS indique un accès par le réseau, une complexité faible, aucun privilège requis et aucune interaction de l'utilisateur. C'est pour cela que le score atteint 10.0. La faille a été signalée par joaxcar via le programme de bug bounty sur HackerOne.
Qui l'exploite ?
Comme le rapporte BleepingComputer, la CISA a ajouté la faille au KEV et a demandé aux agences fédérales de sécuriser leurs serveurs avant dimanche. Selon The Hacker News, l'échéance pour les agences civiles est le 1er novembre 2026.
L'inscription au catalogue fait suite à un incident signalé par Alpine Linux. Un acteur inconnu a tenté sans succès d'exploiter la faille sur son instance les 20 et 21 octobre 2026. Il a envoyé des configurations CI conçues pour l'occasion et a fait planter les processus worker à huit reprises. Dans quatre de ces cas, l'exploit a échoué à l'étape suivante. L'attaquant a aussi téléchargé l'image conteneur GitLab d'Alpine. Les nouvelles tentatives des 25 et 26 octobre ont été bloquées.
Les mainteneurs d'Alpine ont déclaré – « The attack came close to working ». Ils ajoutent n'avoir trouvé aucune preuve de réussite, sans pouvoir l'exclure, et ont donc reconstruit l'instance à partir de zéro. Selon eux, le dépôt aports, les paquets et les releases du 21 octobre n'ont pas été altérés.
Quelles versions sont touchées ?
Pour CVE-2026-97229, GitLab indique toutes les versions à partir de la 19.2 et antérieures à la 19.2.8, à partir de la 19.3 et antérieures à la 19.3.5, et à partir de la 19.4 et antérieures à la 19.4.2. GitLab.com utilise déjà la version corrigée. Les locataires GitLab Dedicated ont été mis à jour avec une version interne avant la publication.
GitLab signale aussi que la 19.3.4 comportait un bug sur les pages des merge requests avec l'intégration Ona activée. Il est corrigé dans la 19.3.5. L'entreprise a par ailleurs publié six règles de détection de menaces pour aider les administrateurs d'instances self-managed à repérer les tentatives d'exploitation.
Les autres failles de ce correctif
La release ne contient pas que le cas le plus grave. Parmi les autres corrections, voici les scores annoncés par GitLab.
- CVE-2026-92883, cross-site scripting dans la coloration syntaxique, CVSS 8.7.
- CVE-2026-16301, un utilisateur Developer pouvait lancer des pipelines sur des branches protégées, CVSS 8.5.
- CVE-2026-14814, empoisonnement du cache des fichiers raw, avec exposition possible de variables protégées, CVSS 8.2.
- CVE-2026-81839, pipelines exécutés avec les privilèges du nouveau groupe après le transfert d'un projet (EE uniquement), CVSS 7.7.
- CVE-2026-96893, injection dans les instructions des agents IA de GitLab Duo (EE uniquement), CVSS 7.3.
Il y a aussi cinq failles de gravité moyenne, dont la lecture de notes confidentielles via GraphQL et l'exposition de jetons dans les journaux de GitLab Pages. Le tableau complet se trouve sur la page officielle.
Les limites à connaître
On ne sait pas combien d'instances ont été compromises. Shadowserver, cité par BleepingComputer, recense près de 2 800 instances Community Edition exposées sur Internet, mais n'indique pas combien sont déjà à jour. Ce chiffre ne doit pas être lu comme le nombre de systèmes vulnérables.
Les sources ne disent pas qui est l'attaquant, ni s'il existe d'autres cas en dehors d'Alpine. Le détail technique de l'exploit n'a pas été publié. GitLab rend public ses rapports de sécurité 90 jours après la publication du correctif, d'autres détails pourraient donc apparaître.
Ce que ça change pour ceux qui travaillent avec le numérique
Si tu utilises un GitLab self-managed pour ton studio ou ton entreprise, la priorité est la version. Une faille sans authentification sur un serveur qui contient du code, des secrets et des pipelines représente un risque concret, y compris pour tes clients. Ceux qui hébergent leur dépôt sur GitLab.com sont déjà protégés côté plateforme.
La leçon d'Alpine est pratique. Si tu ne peux pas exclure une compromission, reconstruis l'instance et renouvelle les secrets. Automatiser les installations aide, comme nous l'expliquons dans le guide sur Ansible pour la configuration et le déploiement. Pour les serveurs, il faut aussi de la rigueur dans les mises à jour, sujet que nous avons traité avec le cas de Fragnesia et PHP2Shell. Autre exemple récent de scans après un correctif – Oracle E-Business Suite. Si tu n'as pas le temps de tout suivre, il existe des hébergements et serveurs gérés avec mises à jour de sécurité.
Notre avis
Ce cas montre à quel point le délai entre correctif et attaque peut être court. Le correctif date du 12 octobre, les tentatives contre Alpine du 20, soit huit jours plus tard. Ceux qui attendent le cycle mensuel suivant arrivent trop tard.
Une remarque critique demeure. GitLab est présenté comme présent chez plus de la moitié des entreprises du Fortune 100, et BleepingComputer recense une série de failles de gravité maximale sur la même période, dont deux autres de gravité maximale. Pour un service qui garde le code et les secrets d'une entreprise, cette fréquence pèse. Il ne suffit pas de dire que GitLab corrige vite, même si c'est le cas. Ceux qui décident de tout garder en interne doivent prévoir une surveillance continue, ou confier cette tâche à des professionnels.
Questions fréquentes
Dois-je mettre à jour GitLab tout de suite ?
Oui, si ton instance est self-managed et se situe dans les versions indiquées. GitLab recommande une mise à jour immédiate vers 19.4.2, 19.3.5 ou 19.2.8. L'exploitation active est confirmée par la CISA.
GitLab.com est-il à risque ?
Non, selon GitLab. GitLab.com utilise déjà la version corrigée et les locataires Dedicated ont été mis à jour avant la publication.
Faut-il un compte pour exploiter la faille ?
Non. Le vecteur CVSS indique qu'aucun privilège n'est requis et qu'aucune interaction de l'utilisateur n'est nécessaire. L'attaque passe par une configuration CI/CD spécialement construite.
Comment savoir si j'ai été attaqué ?
Les sources ne donnent aucun moyen certain. GitLab a publié six règles de détection pour les instances self-managed. Alpine a observé des plantages répétés des workers après des configurations CI anormales.
Suffit-il de mettre à jour ?
Cela dépend. Si l'instance était exposée et non corrigée dans les jours précédents, tu ne peux pas exclure une compromission. Alpine a choisi de la reconstruire entièrement.
Ce qu'il faut surveiller dans les prochaines semaines, entre correctifs et contrôles
Dans les prochains jours, il faudra savoir si d'autres cas apparaissent en dehors d'Alpine et si des détails techniques seront publiés. Trois conseils.
- Mets à jour vers la dernière version disponible pour ta branche et vérifie le numéro après l'installation.
- Contrôle les journaux des workers pour repérer les plantages répétés et les configurations CI inhabituelles, en utilisant les règles de détection de GitLab.
- Si l'instance était exposée et non mise à jour, renouvelle les jetons et les variables protégées, et envisage une reconstruction.
