Si tu gères une instance GitLab self-managed (Community ou Enterprise Edition), il y a de fortes chances que tu aies déjà vu passer une alerte cette semaine : CVE-2026-85706, une faille de traversée de répertoire notée 10.0 sur 10 à l’échelle CVSS — le score maximal possible. Elle permet à un attaquant non authentifié de lire n’importe quel fichier sur ton serveur, y compris du code source et des identifiants, avec une simple requête HTTP. Elle est activement exploitée, elle figure dans le catalogue Known Exploited Vulnerabilities (KEV) de la CISA, et GitLab a publié un correctif d’urgence le 10 septembre 2026.
Si ce n’est pas déjà fait, ce qui suit est prioritaire sur à peu près tout le reste de ta liste de tâches du jour.
Ce que fait exactement la faille
CVE-2026-85706 se situe dans l’API des commits de dépôt de GitLab. Le problème vient d’un défaut de confinement de chemin combiné à une absence de vérification d’authentification sur cet endpoint : un attaquant peut construire une requête qui sort du répertoire attendu pour aller lire des fichiers arbitraires sur le système de fichiers du serveur — configuration, clés, code source privé, tout ce qui est accessible au compte de service GitLab.
Contrairement à beaucoup de vulnérabilités « critiques » qui nécessitent des conditions particulières pour être exploitables, celle-ci ne demande aucune authentification préalable. C’est ce qui explique à la fois le score CVSS maximal et la vitesse à laquelle l’exploitation active a démarré : des chercheurs ont observé du sondage actif dans les jours qui ont suivi la publication du correctif, le temps que les attaquants fassent de la rétro-ingénierie du patch pour reconstruire l’exploit.
Es-tu concerné ?
La faille touche les déploiements self-managed uniquement :
- GitLab CE/EE versions 18.7 à 19.1 (avant 19.1.8)
- GitLab CE/EE versions 19.2 (avant 19.2.6)
- GitLab CE/EE versions 19.3 (avant 19.3.2)
Tous les modes d’installation sont concernés — Omnibus, installation depuis les sources, Helm chart. GitLab.com et les instances Dedicated sont déjà protégées côté GitLab, tu n’as rien à faire pour ces offres managées. Si tu héberges toi-même ton instance, en revanche, la responsabilité du correctif t’incombe entièrement.
Comment corriger
Mets à jour vers l’une des versions patchées selon ta branche actuelle :
# Vérifie ta version actuelle
sudo gitlab-rake gitlab:env:info
# Cible une des versions corrigées selon ta branche
# 19.1.x -> 19.1.8
# 19.2.x -> 19.2.6
# 19.3.x -> 19.3.2
GitLab est explicite sur ce point dans son avis de sécurité officiel : toutes les installations concernées doivent être mises à niveau vers la dernière version dès que possible, en dehors du cycle de correctifs habituel si nécessaire. Ce patch corrige aussi 19 autres vulnérabilités dans la même publication, dont deux autres failles critiques (désérialisation GraphQL et un dépassement de tampon) — une bonne raison supplémentaire de ne pas traîner.
Point opérationnel à anticiper : le correctif inclut des migrations de base de données. Sur une installation mono-nœud, ça se traduit par une interruption de service pendant la mise à jour. Si tu es en configuration multi-nœuds, tu peux appliquer la procédure de mise à niveau zéro downtime documentée par GitLab pour éviter la coupure.
Si tu ne peux pas patcher immédiatement
Une mise à jour d’urgence n’est pas toujours possible dans l’instant, surtout un week-end ou sur une instance avec des dépendances lourdes. En attendant de patcher :
- Restreins l’exposition réseau de ton instance GitLab à un VPN ou une liste d’IP de confiance si ce n’est pas déjà le cas — cette faille ne nécessitant aucune authentification, réduire la surface réseau exposée limite directement le risque
- Surveille tes logs d’accès pour des motifs de requêtes suspectes sur l’API des commits (séquences `../` ou équivalents encodés dans les paramètres d’URL)
- Considère une règle WAF temporaire bloquant les tentatives de traversée de chemin sur les endpoints de l’API des commits, en sachant que ce n’est qu’une mesure d’atténuation, pas un correctif
Aucune de ces mesures ne remplace la mise à jour — elles réduisent la fenêtre de risque, elles ne la ferment pas.
Après le patch : ne t’arrête pas là
Vu la nature de la faille — lecture arbitraire de fichiers, potentiellement des identifiants ou des clés — patcher ne suffit pas si ton instance a été exposée avant la mise à jour. Il est recommandé de traiter cet incident comme une possible compromission :
- Fais tourner (rotate) les secrets et identifiants stockés sur le serveur : clés SSH de déploiement, tokens d’intégration, secrets de variables CI/CD
- Vérifie tes logs d’accès sur la période où ton instance a été exposée pour repérer des requêtes anormales vers l’API des commits
- Si tu disposes d’outils de détection, des règles Sigma et Suricata/Snort spécifiques à cette CVE circulent déjà dans la communauté sécurité pour faciliter la chasse aux indicateurs de compromission
Ce réflexe « patch + rotation + vérification des logs » rejoint directement la logique qu’on avait détaillée pour le Patch Tuesday de septembre : une faille critique activement exploitée se traite comme un incident potentiel, pas comme une simple case à cocher dans un tableau de suivi de patchs.
FAQ
GitLab.com est-il concerné ?
Non. GitLab.com et les instances GitLab Dedicated sont des offres managées par GitLab et ont déjà été protégées côté éditeur. Seules les instances self-managed (que tu héberges et administres toi-même) nécessitent une action de ta part.
Comment savoir si mon instance a déjà été ciblée ?
Recherche dans tes logs d’accès des requêtes vers l’API des commits contenant des séquences de traversée de chemin (`../` ou leurs variantes encodées en URL) sur la période depuis la divulgation de la faille début septembre. Des scanners de détection dédiés à cette CVE sont disponibles publiquement si tu veux automatiser cette recherche.
La CISA impose-t-elle un délai pour ce correctif ?
La CISA a fixé une échéance de remédiation obligatoire au 14 septembre 2026, mais uniquement pour les agences fédérales américaines relevant de sa directive opérationnelle contraignante. Pour toute autre organisation, il n’y a pas d’obligation légale liée à la CISA — ce qui ne change rien à l’urgence réelle, vu l’exploitation active confirmée.
En résumé
Un CVSS de 10.0 combiné à une exploitation active et une absence totale de prérequis d’authentification, c’est la définition même d’une urgence à traiter en dehors des fenêtres de maintenance habituelles. Si tu gères une instance GitLab self-managed en version 19.3.1 ou antérieure, vérifie ta version dès maintenant, planifie la fenêtre de mise à jour si tu es en mono-nœud, et prévois la rotation de tes secrets si l’exposition a duré plus de quelques heures depuis la divulgation.
Laisser un commentaire