CVE-2026-85706 GitLab : patch d'urgence ou migration Gitea

La CVE-2026-85706 est une vulnérabilité de traversée de chemin (path traversal) dans le composant de gestion des dépôts de GitLab CE et EE. Le vecteur CVSS est AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H — aucune authentification requise, aucune interaction utilisateur, impact complet sur la confidentialité, l'intégrité et la disponibilité. En pratique, une requête HTTP malformée contre l'endpoint d'API des archives de dépôt permet à un attaquant de traverser le système de fichiers de l'instance GitLab et d'atteindre des fichiers de configuration sensibles situés en dehors de la racine des dépôts. Le chercheur de watchTowr a publié un proof-of-concept fonctionnel peu après la divulgation, et les équipes Rapid7 ont confirmé des tentatives d'exploitation actives dans leur télémétrie ETR. La CISA a inscrit la CVE-2026-85706 dans son catalogue Known Exploited Vulnerabilities le 10 septembre 2026, ce qui impose aux agences fédérales américaines un délai de remédiation de 72 heures — signal fort de la gravité réelle de la menace.

Les versions GitLab CE et EE de 18.7.0 à 19.3.1 incluse sont vulnérables, qu'elles soient installées via les paquets omnibus, déployées en conteneur Docker ou déployées via Helm sur Kubernetes. GitLab.com (le service SaaS hébergé par GitLab Inc.) a été patché en amont par l'équipe GitLab avant la divulgation publique — les utilisateurs de GitLab.com ne sont pas concernés et n'ont aucune action à entreprendre. Seules les instances auto-hébergées sont exposées. Les versions GitLab antérieures à 18.7 ne sont pas affectées par ce vecteur spécifique, mais elles sont en fin de support et exposées à d'autres vulnérabilités non corrigées ; une mise à jour vers 19.3.2 reste recommandée dans tous les cas. Les instances isolées derrière un pare-feu ou un VPN ne sont pas protégées : le vecteur est HTTP standard sur les ports 80 et 443, un accès réseau interne ou une compromission préalable du VPN suffit à déclencher l'exploitation.

Si votre instance a été exposée sur internet entre la sortie de la version 18.7 et l'application du patch — ou si vous avez le moindre doute — la rotation des secrets est obligatoire. Patcher stoppe l'exploitation future mais ne révoque pas les credentials déjà exfiltrés. Commencez par régénérer la clé de chiffrement de la base de données : sudo gitlab-rake gitlab:encrypted_secrets:rotate_key. Ensuite, révoquez et régénérez tous les tokens de runners CI/CD depuis l'interface d'administration (Admin > CI/CD > Runners), puis reconfigurez chaque agent runner avec le nouveau token via gitlab-runner register. Remplacez les clés SSH déployées sur les runners. Auditez les variables CI/CD de chaque projet (Settings > CI/CD > Variables) et changez tous les secrets de déploiement — clés API cloud, identifiants de registre Docker, tokens d'accès aux services tiers. Notifiez les équipes qui utilisent des pipelines CI/CD de l'instance que leurs secrets de déploiement doivent être considérés comme compromis jusqu'à preuve du contraire.

GitLab CE est une forge Git complète mais son architecture monolithique et sa base de code Ruby on Rails volumineuse élargissent mécaniquement la surface d'attaque. La CVE-2026-85706 n'est pas un incident isolé : GitLab a connu quatre CVE critiques (CVSS ≥ 9.0) au cours des dix-huit derniers mois. Gitea est une alternative en Go, mono-binaire, dont l'empreinte mémoire est environ dix fois inférieure et dont l'historique de CVE critiques est nettement plus court. Pour les équipes dont les besoins se limitent à l'hébergement Git, aux pull requests, aux webhooks et à une intégration CI légère, Gitea couvre l'essentiel avec une surface exposée bien plus réduite. La migration implique l'export des dépôts, des issues, des wikis et des membres depuis GitLab via l'API, puis leur import dans Gitea — un processus documenté dans l'article dédié à la migration GitLab vers Gitea. Sur un VPS à accès root, vous gardez le contrôle complet du calendrier de mise à jour, des sauvegardes et de la rotation des secrets, sans dépendre d'un éditeur tiers pour décider quand votre instance est patchée.

La CVE-2026-85706 illustre un principe fondamental de la sécurité des logiciels auto-hébergés : la fenêtre d'exposition entre la divulgation d'une CVE critique et l'application du patch est la période la plus dangereuse de la vie d'une instance. Sur GitLab.com, cette fenêtre était nulle — l'équipe GitLab a patché silencieusement avant la divulgation. Sur une instance auto-hébergée, la fenêtre dépend entièrement de votre capacité à être alerté, à tester et à déployer rapidement. Un VPS avec accès root vous donne le contrôle total sur ce cycle : vous pouvez automatiser les mises à jour de sécurité avec unattended-upgrades pour les paquets système, mettre en place des alertes sur les CVE via les flux RSS du programme de sécurité GitLab, et tester le patch sur un environnement de staging avant la production. Ce contrôle est aussi une responsabilité : aucun fournisseur cloud ne patchera votre instance GitLab ou Gitea à votre place. La bonne pratique est de traiter les CVE CVSS ≥ 9 comme des incidents de production — plan de remédiation en moins de 24 heures, rotation des secrets en moins de 48 heures. Sur un VPS ServOrbit, les sauvegardes automatiques et l'accès root direct permettent de tenir ce calendrier sans dépendre d'un service managé dont vous ne contrôlez ni les délais ni les procédures.