CVE-2026-85706 : GitLab path traversal CVSS 10.0 exploité

Les faits

Une vulnérabilité de traversée de chemin de sévérité maximale — CVSS 10.0 — a été identifiée dans GitLab Community Edition et Enterprise Edition. Référencée CVE-2026-85706, la faille réside dans le composant body-upload helper qui traite le paramètre file.path avant toute vérification d'authentification, sans restreindre les chemins accédés aux seuls répertoires des dépôts. Un attaquant non authentifié peut soumettre une requête HTTP unique à l'API Repository Commits pour lire n'importe quel fichier accessible au processus GitLab sur le système — sans compte, sans token, sans aucune condition préalable.

Les versions concernées s'étendent de GitLab CE/EE 18.7 jusqu'à 19.3.1 inclus : branches 18.7 à 19.1.7, 19.2.0 à 19.2.5, et 19.3.0 à 19.3.1. Les versions corrigées sont 19.1.8, 19.2.6 et 19.3.2, publiées fin septembre 2026 dans un avis de sécurité d'urgence. Les équipes d'administration peuvent vérifier leur version via gitlab-rake gitlab:env:info ou depuis l'interface d'administration de l'instance.

La nature de la faille — lecture arbitraire de fichiers — expose les secrets d'application stockés dans les fichiers de configuration : tokens d'accès API, clés SSH d'intégration continue, variables d'environnement des pipelines CI/CD contenant des credentials cloud (AWS, Azure, GCP), clés de signature de code, mots de passe de bases de données. Dans un contexte d'entreprise, la compromission d'une instance GitLab peut constituer la porte d'entrée vers l'ensemble de la chaîne de livraison logicielle.

La firme de threat intelligence watchTowr Intel a signalé des sondes d'exploitation actives dès les premières heures suivant la divulgation publique. Ces requêtes automatisées balaient Internet à la recherche d'instances GitLab vulnérables, confirmant que des acteurs malveillants ont rapidement développé des outils d'exploitation. Le cabinet Truesec et le CERT singapourien (CSA) ont publié des alertes indépendantes confirmant l'exploitation dans la nature. SecurityWeek a titré : « Critical GitLab Flaw Exploited Shortly After Disclosure ».

Le 11 septembre 2026, la CISA a officiellement inscrit CVE-2026-85706 à son catalogue Known Exploited Vulnerabilities (KEV). Cette inscription impose aux agences fédérales américaines de patcher avant une date limite fixée et constitue un signal fort pour l'ensemble du marché. Historiquement, les vulnérabilités inscrites au KEV sont exploitées dans 80 % des cas dans les 30 jours suivant leur divulgation — ici, l'exploitation a commencé dans les heures qui ont suivi la publication.

Du point de vue de la chaîne d'approvisionnement logicielle, l'impact potentiel dépasse largement le périmètre direct d'une instance GitLab compromise. Les entreprises utilisant GitLab comme forge centrale peuvent voir leurs secrets CI/CD exfiltrés. Un attaquant récupérant ces éléments peut rebondir vers des systèmes de production sans déclencher d'alertes, en utilisant des credentials légitimes. C'est le scénario qui a permis à plusieurs groupes APT de compromettre des chaînes de développement entières ces dernières années.

La CERT-FR a publié le 30 septembre 2026 l'avis CERTFR-2026-AVI-1242 relatif à cette vulnérabilité, recommandant une mise à jour prioritaire pour toutes les instances GitLab exposées, qu'elles soient accessibles depuis Internet ou uniquement depuis des réseaux internes. Une instance non exposée reste vulnérable si un attaquant déjà présent dans le réseau cherche à pivoter — la traversée de périmètre étant le vecteur d'attaque initial classique des groupes APT ciblant les environnements de développement.

GitLab Self-Managed, GitLab Dedicated et GitLab.com sont concernés. Pour GitLab.com (SaaS managé), GitLab indique avoir appliqué des mitigations côté infrastructure. Les instances auto-hébergées restent entièrement sous la responsabilité de leurs administrateurs. Les données Shodan montrent des dizaines de milliers d'instances GitLab exposées sur Internet en versions 18.x et 19.x — la surface d'attaque mondiale est considérable et largement accessible aux scanners automatisés opérés par les groupes cybercriminels.

Impact et exposition

Tout opérateur d'une instance GitLab CE/EE en versions 18.7 à 19.3.1 est directement exposé. L'exploitation ne requiert aucune condition préalable. Les secrets potentiellement exposés incluent tokens d'accès, clés SSH de déploiement, variables CI/CD avec credentials cloud, et code source propriétaire. Une exploitation réussie peut conduire à une compromission complète de la chaîne de livraison logicielle et à un rebond vers les environnements de production via des credentials volés.

Recommandations

• Mettre à jour vers GitLab 19.1.8, 19.2.6 ou 19.3.2 en priorité absolue — délai maximum recommandé : 24 heures pour toute instance exposée sur Internet.
• Après la mise à jour, effectuer une rotation immédiate de tous les tokens, credentials et clés SSH stockés dans GitLab ou ses pipelines CI/CD.
• Auditer les logs d'accès à l'API Repository Commits pour détecter toute exploitation antérieure — rechercher des séquences ../ ou %2e%2e%2f dans le paramètre file.path.
• Si la mise à jour immédiate est impossible, restreindre l'accès réseau à l'instance GitLab en urgence via firewall ou VPN obligatoire.
• Vérifier les indicateurs de compromission publiés par watchTowr Intel et Truesec pour détecter toute exploitation antérieure.