GitLab : une faille critique activement exploitée vise les serveurs auto-hébergés

Une faille critique, activement exploitée

La vulnérabilité est référencée CVE-2026-85706. La CISA l’a ajoutée à son catalogue des vulnérabilités connues pour être exploitées le 11 septembre 2026. Cette inscription ne signifie pas que toutes les installations GitLab ont été compromises. Elle confirme en revanche que la faille est utilisée dans des attaques réelles et qu’elle ne doit pas être traitée comme un simple risque théorique.

GitLab lui attribue un score CVSS de 10 sur 10, le niveau maximal. L’éditeur explique qu’un utilisateur non authentifié pouvait, dans certaines conditions, lire des fichiers arbitraires du serveur. La cause se situe dans l’API des commits de dépôt : le confinement des chemins de fichiers et le contrôle d’authentification n’étaient pas correctement appliqués.

La CISA décrit elle aussi une lecture de fichiers arbitraires par un attaquant non authentifié. Elle précise que la vulnérabilité concerne GitLab Community Edition et Enterprise Edition. Le point important est donc l’exposition d’une instance auto-hébergée non corrigée, et non l’utilisation de GitLab au sens large par un simple compte utilisateur.

GitLab.com est corrigé, les installations auto-hébergées doivent être vérifiées

GitLab a publié le correctif le 10 septembre 2026 dans les versions 19.1.8, 19.2.6 et 19.3.2. L’éditeur indique que GitLab.com fonctionne déjà avec une version corrigée et que les clients GitLab Dedicated n’ont aucune action à accomplir. Cette précision évite une confusion fréquente : une alerte sur le logiciel GitLab ne signifie pas que le service GitLab.com est vulnérable au moment où elle est lue.

En revanche, une organisation qui exploite elle-même GitLab sur ses propres serveurs doit identifier sa version et son mode de déploiement. Sont concernées les versions à partir de 18.7 et antérieures à 19.1.8, les versions 19.2 antérieures à 19.2.6, et les versions 19.3 antérieures à 19.3.2. GitLab recommande une mise à niveau immédiate vers une version corrigée prise en charge.

Un correctif de cette nature peut nécessiter des opérations préparatoires. GitLab avertit notamment que la mise à jour contient des migrations de base de données. Sur une installation à nœud unique, celles-ci entraînent un arrêt pendant la mise à niveau. Il ne faut pas pour autant repousser indéfiniment l’intervention : cet arrêt doit être préparé, puis le correctif appliqué.

Lire un fichier ne veut pas dire tout savoir sur une intrusion

La lecture arbitraire de fichiers est grave parce qu’un serveur peut contenir des fichiers de configuration, des journaux ou des éléments techniques utiles à une attaque ultérieure. GitLab ne publie pas, dans son avis, la liste exhaustive des fichiers qui auraient été ciblés lors des exploitations observées. Il serait donc incorrect d’affirmer que des dépôts, des mots de passe ou des jetons ont été lus dans tous les cas.

GitLab a toutefois publié trois détections pour les clients qui exploitent eux-mêmes le produit : une tentative de lecture de gitlab.yml, une tentative passant par le paramètre metadata.path et une tentative de chemin de fichier. Elles servent à rechercher des indices dans les journaux et ne constituent pas, à elles seules, une preuve de compromission.

Le catalogue de la CISA marque également cette entrée comme nécessitant un triage forensique. En clair, l’organisation ne doit pas seulement installer le correctif. Elle doit aussi examiner les traces disponibles pour déterminer si une tentative ou une exploitation a précédé la mise à jour.

Le réflexe utile : faire contrôler l’instance, pas cliquer dans un message d’alerte

Cette alerte vise d’abord les administrateurs d’instances GitLab auto-hébergées. Si votre entreprise utilise GitLab mais que vous ne savez pas où il est administré, transmettez l’information à la personne ou au prestataire qui gère la plateforme. Le message essentiel est précis : vérifier CVE-2026-85706, la version installée et l’exposition éventuelle du serveur.

Pour un utilisateur de GitLab.com ou d’un GitLab géré par une autre organisation, évitez de vous précipiter sur un lien reçu par courriel ou messagerie qui prétend proposer une mise à jour de sécurité. L’avis officiel précise que GitLab.com est déjà corrigé. En cas de doute, rejoignez le service par vos favoris ou par l’adresse habituelle, puis demandez confirmation au canal informatique connu.

Pour les équipes techniques, le correctif et la recherche de traces doivent aller ensemble. Mettre à jour ferme la porte pour les tentatives futures. Lire les journaux permet de savoir si la porte a pu être franchie avant sa fermeture.

Ce que nous ne pouvons pas vérifier

Nous ne pouvons pas vérifier combien d’instances GitLab ont été visées ou compromises. Ni GitLab ni la CISA ne publient de nombre de victimes dans les documents consultés. La présence de la faille dans le catalogue de la CISA confirme une exploitation active, pas l’ampleur de celle-ci.

Nous ne pouvons pas identifier les auteurs des attaques, leurs objectifs, ni les fichiers effectivement lus dans chaque intrusion. Le catalogue de la CISA indique que l’utilisation dans une campagne de rançongiciel est inconnue. Il ne faut donc pas présenter cette alerte comme un rançongiciel confirmé.

Enfin, nous ne pouvons pas déterminer à distance si une installation précise est concernée ou a subi une tentative. Cette vérification dépend de la version, de l’exposition de l’instance et des journaux accessibles à son administrateur.

Sources : GitLab ↗ · CISA ↗

Article rédigé et vérifié par Cyberfaille, avec assistance IA. Un doute, une correction ? écrivez-nous.