CVE-2026-85706 : faille critique dans GitLab permettant de dérober des fichiers sans identifiants

CVE-2026-85706 : faille critique dans GitLab permettant de dérober des fichiers sans identifiants

En bref

GitLab a confirmé une vulnérabilité critique (CVE-2026-85706, CVSS 10.0) permettant à un attaquant sans identifiants de lire des fichiers arbitraires sur le serveur [1]. Elle figure au catalogue CISA KEV des vulnérabilités activement exploitées [2]. Elle affecte les instances GitLab Community et Enterprise Edition [1]. Si votre entreprise utilise GitLab, la priorité du jour est d'identifier la version installée et d'appliquer le correctif correspondant sans délai.

De quoi s'agit-il et pourquoi est-ce important

La vulnérabilité réside dans l'API de commits des dépôts de GitLab. Selon la description officielle, une faille de confinement de chemins (« path confinement ») combinée à une absence de vérification d'authentification permet à un utilisateur non authentifié d'accéder à des fichiers arbitraires du serveur au moyen de techniques de path traversal [1]. Le NVD l'a qualifiée de sévérité critique avec un score CVSS de 10.0, le maximum possible [1], ce qui reflète le fait qu'elle peut être exploitée à distance, sans privilèges ni interaction de l'utilisateur, et avec un impact potentiellement total sur la confidentialité des données.

L'équipe de veille d'OCIRIA a classé cette vulnérabilité comme « Path traversal / accès à des fichiers » et souligne que, ne nécessitant aucune authentification, toute instance GitLab exposée à internet constitue une cible directe : code source, fichiers de configuration contenant des secrets, variables d'environnement ou identifiants stockés dans le dépôt pourraient être exposés sans laisser de trace d'accès authentifié.

Le fait que la vulnérabilité figure dans le catalogue CISA KEV est une donnée importante : cela signifie qu'il existe une preuve d'exploitation active dans le monde réel, et non un simple risque théorique [2].

Qui est concerné

Elle affecte les organisations qui exploitent des instances propres (self-managed) de GitLab Community Edition (CE) ou Enterprise Edition (EE) [1]. Selon la description officielle de l'éditeur, la plage de versions concernées s'étend de la série 18.7 jusqu'à des versions spécifiques des séries 19.0, 19.1, 19.2 et 19.3, chacune disposant de sa version corrigée correspondante [1]. Étant donné l'ampleur de cette plage, toute équipe de développement, DevOps ou plateforme qui maintient GitLab on-premise ou sur infrastructure propre doit se considérer comme potentiellement exposée tant qu'elle n'a pas vérifié sa version précise.

Les organisations utilisant GitLab.com (SaaS) géré directement par GitLab reçoivent généralement les correctifs de manière centralisée, mais il convient de le confirmer auprès de l'équipe responsable de ce compte en cas de doute sur le modèle de déploiement.

Comment savoir si vous êtes vulnérable

• Identifiez la version exacte de GitLab CE/EE déployée (visible dans le panneau d'administration ou sur le endpoint /help).
• Comparez cette version aux plages affectées indiquées par l'éditeur [1] : 18.7–18.11.12, 19.0–19.0.9, 19.1–19.1.8, 19.2–19.2.6 et 19.3–19.3.2.
• Vérifiez si votre instance GitLab est accessible depuis internet sans restrictions réseau (VPN, liste blanche d'IP), car l'exploitation ne nécessite pas d'authentification.
• Dans le cadre de votre hygiène de sécurité générale, il convient de cartographier quels actifs et services de votre organisation sont exposés à internet ; le radar de surface d'OCIRIA est justement conçu pour détecter ce type d'exposition en continu.

Comment vous protéger

1. Mettez à jour GitLab immédiatement vers la première version corrigée de votre branche (18.11.12, 19.0.9, 19.1.8, 19.2.6 ou 19.3.2, selon le cas) [1].

2. Restreignez l'accès réseau à l'instance pendant que vous finalisez la mise à jour : limitez l'accès aux IP de confiance ou au VPN de l'entreprise.

3. Auditez les journaux d'accès à l'API de commits pour la période durant laquelle votre instance était en version vulnérable, à la recherche de schémas de path traversal ou d'accès anormaux sans authentification.

4. Faites tourner les identifiants et secrets qui pourraient être stockés dans des dépôts ou des fichiers de configuration accessibles, par mesure de précaution face à une exposition éventuelle.

5. Priorisez ce correctif par rapport aux autres en attente : la combinaison d'un CVSS de 10.0 et de la présence dans le catalogue CISA KEV indique un risque maximal et une exploitation connue [1][2].

FAQ

Dois-je être authentifié pour être attaqué ? Non. La vulnérabilité permet l'accès à un attaquant sans identifiants, ce qui la rend particulièrement dangereuse [1].

Existe-t-il des preuves d'exploitation active ? Oui, la vulnérabilité est inscrite au catalogue CISA KEV, qui recense les vulnérabilités dont l'exploitation active est confirmée [2].

Cela affecte-t-il aussi GitLab.com ? La description officielle concerne les instances GitLab CE/EE ; si vous utilisez GitLab.com en tant que service géré, confirmez auprès de votre fournisseur l'état du correctif.

Suffit-il de mettre à jour ou dois-je faire autre chose ? La mise à jour est l'étape indispensable, mais compte tenu du risque d'exposition de fichiers pendant la période vulnérable, vérifier les journaux et faire tourner les identifiants sensibles constitue une précaution raisonnable.

Sources

• [1] https://nvd.nist.gov/vuln/detail/CVE-2026-85706
• [2] https://raw.githubusercontent.com/cisagov/kev-data/develop/known_exploited_vulnerabilities.json