Dans cet article
Si votre entreprise héberge GitLab sur son propre serveur, mettez-le à jour aujourd'hui. Le 12 octobre 2026, GitLab a publié un correctif de sécurité critique qui corrige 24 vulnérabilités. La plus grave, CVE-2026-97229, a reçu la note de gravité maximale : 10 sur 10. Elle permet à une personne qui n'a aucun compte sur votre serveur d'y exécuter son propre code. Sont concernés tous les serveurs en version 19.2 avant 19.2.8, 19.3 avant 19.3.5 ou 19.4 avant 19.4.2. La seule solution indiquée par GitLab est la mise à niveau vers 19.4.2, 19.3.5 ou 19.2.8. Si vous utilisez le service cloud GitLab.com, vous n'avez rien à faire.
Qu'est-ce que GitLab, et pourquoi un dirigeant devrait-il s'en soucier ?
GitLab est l'outil où votre équipe technique conserve le code source de vos systèmes et applications, et d'où partent les nouvelles versions vers vos serveurs. Beaucoup d'entreprises l'hébergent sur un serveur interne plutôt que dans le cloud, pour garder le code et les données chez elles. Ce serveur contient souvent plus que ce qu'imagine le dirigeant : tout le code source, les mots de passe des bases de données, les clés qui relient l'entreprise aux passerelles de paiement et aux services administratifs, et le droit de déployer sur les serveurs qu'utilisent vos clients. Celui qui le contrôle peut tout lire, et modifier votre code avant qu'il n'atteigne vos clients.
Qu'a annoncé GitLab exactement ?
Selon l'annonce officielle du correctif publiée par GitLab, la faille se trouve dans le composant qui traite les expressions régulières dans les paramètres des chaînes de construction et de déploiement (CI/CD). Une expression régulière est un court texte qui décrit un motif de recherche. L'annonce indique que la faille pouvait permettre à un utilisateur non authentifié d'exécuter du code arbitraire sur le serveur GitLab au moyen d'une expression régulière spécialement conçue, faute d'une validation suffisante de ces expressions. Un chercheur l'a signalée via le programme de bug bounty de GitLab sur HackerOne.
L'annonce ne dit pas que la faille a été exploitée. Mais une note de 10 signifie qu'elle peut l'être par Internet, sans mot de passe et sans l'aide d'aucun employé. Les attaquants commencent généralement à chercher ce type de faille quelques jours après la publication d'un correctif, car le correctif lui-même indique où se trouve la faiblesse.
Que contient d'autre ce correctif ?
Le même correctif traite 23 autres vulnérabilités, dont cinq de gravité élevée :
- Une injection de script malveillant (XSS) dans la coloration syntaxique, notée 8,7.
- Une faille d'autorisation lors de la création des pipelines, notée 8,5.
- Une expression régulière trop permissive touchant l'accès aux fichiers, notée 8,2.
- Une faille d'autorisation dans les politiques d'exécution des pipelines de l'édition payante, notée 7,7.
- Une injection d'instructions (prompt injection) dans l'agent d'IA GitLab Duo de l'édition payante, notée 7,3.
Les versions antérieures à 19.2, que la faille critique ne touche pas, ne sont donc pas forcément sûres. La politique de maintenance officielle de GitLab précise que les correctifs de sécurité ne sont reportés que sur la version actuelle et les deux versions mensuelles précédentes. Un serveur plus ancien ne reçoit plus aucun correctif de sécurité et doit de toute façon être mis à niveau.
Qui doit agir ?
- Utilisateurs du cloud GitLab.com : rien à faire ; selon GitLab, le service tourne déjà sur la version corrigée.
- Clients GitLab Dedicated : rien à faire non plus, selon l'annonce.
- Toute entreprise qui héberge GitLab sur son propre serveur : mise à niveau immédiate. C'est la recommandation explicite de GitLab pour toute installation autogérée.
- Toute entreprise qui ne sait pas où tourne son GitLab : posez la question aujourd'hui à votre équipe ou au prestataire qui a construit vos systèmes. Beaucoup de serveurs internes ont été installés par un ancien prestataire, puis oubliés.
Les gestes concrets de cette semaine
- Identifiez la version : demandez à votre responsable technique d'ouvrir la page d'aide de GitLab, d'y lire le numéro de version et de le comparer aux numéros ci-dessus.
- Planifiez la mise à niveau aujourd'hui, pas en fin de mois : d'après l'annonce de GitLab, un serveur unique est indisponible pendant le correctif jusqu'à la fin des migrations de la base de données, alors qu'une installation multi-nœuds peut être corrigée sans interruption si la procédure prévue est suivie. Une heure d'arrêt hors des heures de travail coûte bien moins cher qu'un serveur compromis.
- Si vous êtes en 19.3 : passez directement à 19.3.5, pas à 19.3.4. L'annonce signale que la 19.3.4 comportait un bug sur les pages de merge request lorsque l'intégration Ona était activée, corrigé en 19.3.5.
- Réduisez l'exposition à Internet : si personne hors de l'entreprise n'a besoin d'atteindre votre serveur GitLab, n'acceptez les connexions que depuis le réseau de l'entreprise ou via un VPN. Cela ne remplace pas le correctif, mais réduit la porte d'entrée la prochaine fois.
- Vérifiez après la mise à jour : passez en revue les utilisateurs, clés et jetons d'accès créés récemment. Si quelque chose n'est reconnu par personne, changez les mots de passe et les clés stockés sur le serveur.
Les étapes de mise à niveau pour chaque méthode d'installation figurent dans le guide de mise à niveau officiel de GitLab.
Le regard d'Origami
Nous utilisons GitLab tous les jours, puisque nos dépôts y sont hébergés, et nous suivons ses annonces de sécurité d'aussi près que nos factures. La leçon dépasse GitLab : tout système que vous hébergez vous-même pour garder vos données chez vous s'accompagne du devoir de le corriger le jour même où un correctif sort. Le problème que nous voyons le plus souvent n'est pas ce choix, mais l'absence d'un nom responsable des mises à jour. Un serveur installé par un prestataire il y a trois ans, dont personne ne sait qui l'entretient, est la première chose que cherche un attaquant. Nous disions la même chose à propos de la faille des boutiques Magento : corriger ne suffit pas si l'on corrige trop tard. Si vous avez besoin de quelqu'un pour auditer vos serveurs ou prendre en charge leurs mises à jour, contactez-nous.
Sources
Questions fréquentes
Mon entreprise est-elle touchée par la nouvelle faille GitLab CVE-2026-97229 ?
Oui si vous hébergez GitLab sur votre propre serveur en version 19.2 avant 19.2.8, 19.3 avant 19.3.5 ou 19.4 avant 19.4.2. Selon GitLab, les utilisateurs du cloud GitLab.com et les clients GitLab Dedicated n'ont rien à faire.
Vers quelle version dois-je mettre à niveau ?
Vers 19.4.2, 19.3.5 ou 19.2.8, les versions publiées par GitLab le 12 octobre 2026. En 19.3, passez directement à 19.3.5, car la 19.3.4 comportait un bug corrigé en 19.3.5.
GitLab est-il indisponible pendant la mise à jour ?
Un serveur unique est indisponible pendant le correctif jusqu'à la fin des migrations de la base de données, alors qu'une installation multi-nœuds peut être corrigée sans interruption en suivant la procédure documentée par GitLab. Planifiez-la hors des heures de travail, le jour même.
Notre serveur tourne sur une version antérieure à 19.2. Sommes-nous protégés ?
Vous n'êtes pas touchés par cette faille critique précise, mais la politique de GitLab limite les correctifs de sécurité à la version actuelle et aux deux versions mensuelles précédentes : une version plus ancienne ne reçoit plus aucun correctif de sécurité et doit être mise à niveau.
Suivez Origami sur Google
Ajoutez Origami à vos sources préférées : nos articles apparaîtront en premier pour vous dans la recherche Google et les actualités à la une.
