GitLab : la faille critique peut lire des secrets sans authentification

24 septembre 2026 à 15:00|Auteur: Équipe éditoriale de QUASA|5 min de lecture| 8

Le 17 septembre 2026, GitLab a publié une méthode de validation fondée sur les journaux pour CVE-2026-85706. Cette traversée de chemin dans l’API des commits permet à une requête non authentifiée de faire ouvrir au serveur un fichier arbitraire ; les installations GitLab Self-Managed non corrigées au moment d’une attaque sont les principales concernées.

GitLab.com et GitLab Dedicated sont déjà corrigés. Pour les administrateurs d’instances autogérées, une requête suspecte ou son seul code HTTP ne suffit pas à prouver une fuite : il faut distinguer une tentative infructueuse, une lecture locale sans retour de données et un fragment effectivement envoyé au client.

L’exposition dépend de l’hébergement et de l’historique

La vulnérabilité associe un confinement incorrect des chemins à l’absence de contrôle d’authentification dans l’API des commits de dépôts. Une requête POST peut fournir, dans file.path ou metadata.path, un emplacement situé hors du répertoire temporaire attendu, /uploads/tmp/. Le serveur ouvre alors le chemin demandé à la place du tampon de téléversement prévu.

L’action à mener varie selon l’environnement :

GitLab.com ou GitLab Dedicated : l’infrastructure gérée par GitLab est corrigée ; aucune intervention du client n’est requise pour cette faille.
Self-Managed encore vulnérable : la mise à niveau est prioritaire, suivie de la conservation et de l’examen des journaux.
Self-Managed désormais corrigé : une analyse reste nécessaire si l’instance était accessible avant la mise à jour, car le correctif n’exclut pas une divulgation antérieure.

Cette portée couvre Community Edition et Enterprise Edition, indépendamment du mode de déploiement autogéré. Le point déterminant n’est donc pas l’édition commerciale, mais le fait que l’organisation exploitait elle-même une version vulnérable.

Les correctifs sont disponibles dans trois branches

L’avis de sécurité publié le 10 septembre attribue à CVE-2026-85706 un score CVSS de 10,0 et confirme les versions corrigées 19.1.8, 19.2.6 et 19.3.2. Les plages affectées commencent à la version 18.7 et s’arrêtent avant 19.1.8, puis couvrent les branches 19.2 avant 19.2.6 et 19.3 avant 19.3.2.

Versions 18.7 à 19.1.7 : passer au minimum à 19.1.8.
Versions 19.2 à 19.2.5 : passer au minimum à 19.2.6.
Versions 19.3 à 19.3.1 : passer au minimum à 19.3.2.

Le correctif comporte des migrations de base de données. Une instance à nœud unique subit une interruption pendant leur exécution ; une architecture multinœud correctement préparée peut appliquer la procédure de mise à niveau sans interruption.

L’exploitation active impose de préserver les traces

Le Centre canadien pour la cybersécurité date du 11 septembre 2026 l’ajout de CVE-2026-85706 au catalogue Known Exploited Vulnerabilities de la CISA. Cette inscription repose sur des preuves d’exploitation active, mais ne démontre pas qu’une requête donnée a réussi à extraire un fichier d’une instance particulière.

Avant une mise à niveau ou un redémarrage, les éléments utiles sont api_json.log, le journal d’accès Workhorse et, selon le déploiement, les journaux du proxy web. Un redémarrage peut provoquer la rotation du journal Workhorse et faire disparaître les entrées nécessaires. Les copies doivent être protégées comme des données sensibles, car api_error peut contenir le fragment réellement retourné.

La recherche commence par les requêtes POST vers l’API des commits comportant un paramètre file.path ou metadata.path. La route, le nom du paramètre et sa valeur pouvant être encodés, chaque chemin doit être décodé puis normalisé en résolvant les segments « .. » ; une simple recherche de chaîne littérale risque de manquer une tentative.

Pour chaque chemin sortant de /uploads/tmp/, le correlation_id de l’entrée Rails permet de retrouver la ligne correspondante dans le journal Workhorse. Le champ written_bytes fournit alors le nombre d’octets effectivement transmis au client pour cette requête.

written_bytes et api_error séparent lecture et exfiltration

La réponse associée à un fichier introuvable comporte normalement un corps de 54 octets. Cette valeur doit toutefois être contrôlée sur l’instance concernée : la compression, un proxy inverse ou une différence entre l’état corrigé et l’ancien état vulnérable peuvent modifier la référence observable.

api_error absent et written_bytes au niveau de référence : le chemin n’a pas mené à un fichier lisible ; aucun contenu n’a été divulgué.
api_error absent et réponse plus courte : le fichier a pu être ouvert et lu localement, mais son contenu n’a pas été renvoyé. La procédure documente notamment un corps « 401 Unauthorized » de 30 octets.
api_error présent avec un fragment et written_bytes supérieur à la référence : le fragment a été envoyé au client ; l’exfiltration est établie pour les octets visibles dans ce champ.

Le code HTTP isolé ne permet pas ce classement. Une réponse 400 peut contenir des données ou signaler seulement un chemin inexistant, tandis qu’une réponse 401 peut suivre une lecture locale sans divulgation. written_bytes ne représente pas non plus la taille du secret : la mesure inclut l’enveloppe JSON et l’échappement du fragment.

Pourquoi un fichier lu n’est pas toujours renvoyé

Le contenu ouvert est traité comme une donnée de formulaire et soumis au décodage des séquences en pourcentage. Il n’entre dans la réponse que si ce traitement rencontre un caractère « % » qui n’est pas suivi de deux chiffres hexadécimaux ; l’erreur de décodage incorpore alors la portion fautive dans api_error.

Un fichier sans séquence de ce type peut donc être lu intégralement sans qu’un de ses octets soit divulgué. C’est notamment le cas habituel des clés privées OpenSSH et d’autres contenus PEM dont le corps en base64 ne comporte pas de signe « % ». À l’inverse, trouver aujourd’hui un pourcentage invalide dans le fichier ne prouve pas ce qui était présent ni ce qui a été transmis au moment de la requête.

L’état d’un incident doit finalement être établi trace par trace : tentative sans fichier lisible, lecture locale sans contenu retourné, ou fragment effectivement exfiltré. Les correctifs ferment la vulnérabilité, mais seule la corrélation de journaux complets permet d’affirmer qu’un secret précis a quitté une instance Self-Managed auparavant exposée.