GitLab 19.3.2 referme une lecture de fichier arbitraire non authentifiée et dix-sept autres failles
GitLab a publié le 10 septembre 2026 les versions 19.3.2, 19.2.6 et 19.1.8 pour corriger dix-huit failles, dont une lecture de fichier arbitraire sans authentification via l’API des commits et une désérialisation notée CVSS 9,9. Toute instance auto-hébergée exposée doit être mise à jour sans attendre, et les secrets des variables CI/CD passés en revue.
10 septembre 2026. GitLab publie les versions 19.3.2, 19.2.6 et 19.1.8 de ses éditions Community et Enterprise, refermant dix-huit failles. Au centre du lot, CVE-2026-85706, une lecture de fichier arbitraire sans authentification via l’API des commits, et CVE-2026-87719, une désérialisation notée CVSS 9,9 réservée à l’édition Enterprise. GitLab.com tourne déjà sur le code corrigé. Pour qui auto-héberge sa forge, la consigne est simple : la lecture de fichier non authentifiée change la donne, car elle expose les secrets de configuration avant même toute exécution de code.
La faille qui ne demande aucun compte
CVE-2026-85706 est la plus dangereuse du lot, et pas seulement par son score. C’est une traversée de chemin dans l’API des commits de dépôt, doublée d’un défaut d’application de l’authentification sur ce chemin. Résultat : un attaquant distant sans compte, sans interaction et sans privilège peut lire des fichiers arbitraires sur le serveur GitLab.
Ce que l’attaquant vise en priorité, ce ne sont pas vos dépôts. Ce sont les fichiers où GitLab stocke sa propre configuration : les secrets, les jetons, les identifiants et les clés qui traînent dans des chemins accessibles au processus. Une fois ces secrets lus, l’intrusion devient silencieuse — l’attaquant s’authentifie ensuite comme un utilisateur légitime, et rien dans les journaux d’accès ne ressemble à une effraction.
GitLab attribue à la faille un vecteur AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N : réseau, complexité faible, aucun privilège, aucun prérequis, portée changée, impact élevé sur la confidentialité et l’intégrité. Les versions affectées vont de 18.7 à 19.1.8, de 19.2 à 19.2.6 et de 19.3 à 19.3.2.
Une désérialisation à 9,9 côté Enterprise
Le deuxième danger est réservé à l’édition Enterprise. CVE-2026-87719 est une désérialisation non sécurisée dans le sérialiseur d’abonnements GraphQL. Un attaquant authentifié disposant d’un accès Duo Chat peut soumettre un argument d’abonnement GraphQL forgé pour contourner les contrôles de sérialisation et déclencher des recherches d’objets serveur.
La conséquence, c’est l’exposition des configurations d’instance de recherche avancée et d’identifiants sensibles. GitLab note la faille CVSS 9,9, avec un impact élevé sur la confidentialité, l’intégrité et la disponibilité. Les versions Enterprise affectées commencent à 18.3 et s’étendent jusqu’aux branches 19.1, 19.2 et 19.3 non corrigées.
Le point commun des deux failles mérite d’être souligné : elles transforment des mécanismes internes (l’API des commits, le sérialiseur d’abonnements) en canaux de fuite. Ni l’une ni l’autre ne nécessite d’écrire dans un dépôt. C’est de la lecture pure, la phase la plus difficile à détecter d’une compromission.
Le CI/CD n’est pas épargné
Le lot referme aussi CVE-2026-88765, une faille du workflow d’indexation de la recherche avancée : un utilisateur authentifié peut importer un export de projet Git malveillant conçu pour faire déborder un tampon de conversion Unicode, et potentiellement aboutir à une exécution de code à distance. Exploitable seulement avec des identifiants valides et une complexité d’attaque élevée, elle reste notée CVSS 8,5 et touche les versions depuis 12.3.
Plus insidieux encore, CVE-2026-79708 : des développeurs pouvaient exécuter des tests planifiés de politiques d’exécution de pipeline et accéder à des variables CI/CD protégées normalement réservées à des rôles plus élevés. Or ces variables contiennent précisément ce qu’un attaquant veut : des clés cloud, des identifiants de déploiement, des jetons d’API et des secrets de signature. Une élévation silencieuse au cœur du pipeline.
S’y ajoutent une faille d’autorisation sur les portées de variables d’environnement CI/CD, un cross-site scripting dans le rendu des tables JSON Markdown, et deux failles du limiteur de complexité GraphQL exploitables pour du déni de service sans authentification. Pris ensemble, ces éléments dessinent un portrait cohérent : la surface CI/CD et API de GitLab est devenue la cible privilégiée, au même titre que le dépôt de code.
La mise à jour n’est pas anodine
GitLab prévient : le correctif inclut des migrations de base de données. Sur une instance mono-nœud, la mise à jour entraîne une interruption — les migrations doivent se terminer avant que GitLab ne redémarre. Pour une instance multi-nœuds correctement configurée, les procédures de mise à jour sans interruption restent disponibles, et la 19.3.2 embarque des migrations post-déploiement.
La commande de mise à jour, pour un Omnibus sur Debian, suit le schéma habituel :
sudo apt-get update && sudo apt-get install gitlab-ee=19.3.2-ee.0Mais la version n’est qu’une partie du travail. GitLab recommande explicitement de recenser les instances auto-hébergées exposées, de prioriser celles qui sont joignables depuis Internet, puis de renouveler les identifiants potentiellement exposés et de revoir les journaux à la recherche d’activité suspecte sur les commits, les abonnements GraphQL, les imports de projets et les pipelines CI/CD.
Verdict
GitLab 19.3.2 est une correction obligatoire et urgente pour toute instance auto-hébergée, mais la faille la plus grave — la lecture de fichier non authentifiée — ne se corrige pas qu’avec un paquet. Elle exige de renouveler les secrets qui ont pu être lus, faute de quoi l’attaquant conserve ses accès après le patch.
Si vous auto-hébergez GitLab exposé sur Internet, passez en 19.3.2, 19.2.6 ou 19.1.8 dès maintenant, planifiez la fenêtre de migration, puis renouvelez les secrets de configuration et revoquez les variables CI/CD protégées avant de les redéployer.
Si vous êtes sur GitLab.com ou GitLab Dedicated, vous n’avez rien à faire sur ce lot — mais profitez-en pour auditer vos variables CI/CD et vos jetons à portée réduite : ce sont les mêmes chemins que les attaquants ciblent en premier, et le prochain lot ne vous préviendra peut-être pas avec une lecture de fichier aussi visible.