Un seul projet public est la seule condition requise
La CVE-2026-85706 ne demande presque rien à un attaquant. La faille se trouve dans l'API des commits de dépôts GitLab, où un confinement de chemin défaillant et l'absence de vérification d'authentification permettent à un utilisateur non authentifié d'envoyer une requête contenant un paramètre de chemin de fichier et de récupérer n'importe quel fichier du serveur, sans connexion. Jake Knott, de watchTowr, a résumé la barrière à l'entrée en une phrase: "L'exploitation ne demande qu'une seule condition, il faut qu'au moins un projet public existe." La plupart des instances GitLab auto-hébergées en comptent au moins une, que leur propriétaire la considère comme exposée au public ou non.
La faille obtient un score CVSS de 10.0, le maximum de l'échelle, et touche GitLab Community et Enterprise Edition dans les versions 18.7 à 19.1.7, 19.2 à 19.2.5 et 19.3 à 19.3.1. Un serveur ainsi exposé ne se contente pas de laisser fuir du code source. L'API des commits se trouve assez près des fichiers de configuration, des définitions de pipelines CI/CD et des jetons de déploiement pour qu'une lecture réussie livre à l'attaquant les identifiants nécessaires pour s'enfoncer plus loin dans ce que cette instance GitLab construit et déploie.
Un correctif existait avant l'échéance
| Date | Événement |
|---|---|
| 10 septembre | GitLab publie le correctif dans les versions 19.1.8, 19.2.6 et 19.3.2 |
| 11 septembre, 06:00 UTC | Le réseau de honeypots de watchTowr détecte les premières tentatives d'exploitation en conditions réelles |
| 11 septembre | La CISA ajoute la CVE-2026-85706 à son catalogue des vulnérabilités exploitées connues |
| 14 septembre | Échéance pour que les agences fédérales civiles américaines aient corrigé la faille |
Moins de 24 heures ont séparé la publication du correctif des premières tentatives détectées sur les honeypots de watchTowr. L'entrée de la CISA dans son propre catalogue a suivi quelques heures plus tard à peine. Pour watchTowr, les attaquants avaient déjà fait de la rétro-ingénierie et reproduit la vulnérabilité à partir du correctif lui-même, le même schéma qui transforme une divulgation en course dès l'instant où elle devient publique. Le délai de la CISA ne lie que les agences fédérales civiles américaines, pas une entreprise de Munich ou de Manchester, mais la chronologie d'exploitation à laquelle il répond ne s'arrête pas à cette frontière.
La troisième faille que Servola suit depuis août
Ce n'est pas la première faille critique de GitLab cet été: c'est la troisième activement sondée en à peine quatre semaines. Servola a couvert une faille GitLab groupée avec des problèmes critiques dans Ray et les logiciels Apple le 18 août, puis une faille d'injection de code GraphQL dans GitLab lui-même, la CVE-2026-19478, le 24 août, un bug auquel le propre article de TheHackerNews sur cette nouvelle faille renvoie explicitement comme précédent cas d'exploitation survenu peu après la divulgation. Trois CVE critiques contre une plateforme largement auto-hébergée en un mois, ce n'est pas une coïncidence à balayer d'un revers de main comme de la malchance. C'est le signe que la surface d'attaque de GitLab et la vitesse à laquelle chercheurs et attaquants rétro-conçoivent désormais un correctif ont dépassé la fréquence à laquelle la plupart des propriétaires en auto-hébergement vérifient les mises à jour.
Aucune des trois failles ne partage la même cause. Ce qu'elles ont en commun, c'est une fenêtre comprimée: chacune a été sondée ou exploitée en quelques jours après la publication de son correctif, pas en quelques semaines. Un propriétaire qui vérifiait les mises à jour GitLab une fois par mois aurait manqué la fenêtre de sécurité dans les trois cas.
Ce qui change pour une entreprise utilisant GitLab en auto-hébergement
La mesure concrète est modeste: vérifiez que votre instance tourne en 19.1.8, 19.2.6, 19.3.2 ou une version ultérieure, puis examinez les journaux d'accès à la recherche de requêtes POST visant le point de terminaison des commits de dépôt avec un paramètre de chemin de fichier, l'indicateur que watchTowr recommande de traquer. La mesure la plus large est celle qui prévient réellement une répétition. La directive NIS2 demande déjà aux organisations européennes de démontrer qu'elles peuvent vérifier qu'un correctif a bien atteint chaque système géré, pas seulement que GitLab en a publié un. Une instance auto-hébergée sans personne chargé de surveiller en temps réel le catalogue KEV de la CISA ou les avis de sécurité de GitLab continuera de découvrir ses failles critiques par un article de presse plutôt que par une alerte de surveillance. En France, cette exigence recoupe largement ce que l'ANSSI attend déjà des organisations sur le suivi effectif des correctifs.
Une entreprise qui traite chacune de ces failles comme un exercice incendie isolé s'en sortira bien cette fois-ci et manquera la suivante à la même vitesse. Une entreprise qui confie à quelqu'un la responsabilité du rythme de correctifs de GitLab, comme elle le fait pour ses règles de pare-feu, cesse d'être trois fois de suite la dernière à s'en apercevoir.
À lire ensuite: Exploité Des Semaines Avant Que PaperCut Ne Corrige | GitLab critique frappe le self-hosted, pas le SaaS
