GitLab CVE-2026-19478 : une injection GraphQL non authentifiée exploitée en 48h

> En bref : CVE-2026-19478 est une faille critique (CVSS 9.4) dans GitLab CE et EE qui permet une injection de code non authentifiée via l'API GraphQL. Un attaquant distant, sans aucun identifiant, peut modifier ou supprimer des projets publics, fabriquer de faux enregistrements de merge, ou bannir des mainteneurs. Un PoC public a été exploité en conditions réelles dans les deux jours suivant la divulgation.

La faille

Le problème (CWE-94, injection de code) vient d'une mauvaise validation d'une directive GraphQL. En envoyant une requête GraphQL forgée contenant cette directive à une instance GitLab exposée sur internet, un attaquant peut :

Aucune authentification, aucun identifiant, aucune interaction utilisateur n'est requise. C'est une combinaison rare et particulièrement dangereuse pour un outil aussi central que GitLab dans une chaîne CI/CD.

Versions affectées

GitLab CE/EE 18.2 (avant 18.11.11), 19.0 (avant 19.0.8), 19.1 (avant 19.1.6) et 19.2 (avant 19.2.4).

Chronologie d'exploitation

Les chercheurs de watchTowr et Horizon3.ai ont publié une preuve de concept fonctionnelle en quelques minutes après la divulgation publique. L'exploitation en conditions réelles a été observée dans les 48 heures — un délai de plus en plus court qui reflète une tendance de fond : l'automatisation (parfois assistée par l'IA) accélère la réutilisation des PoC publiés.

Indicateur de détection : recherchez dans vos logs de serveur web des requêtes GraphQL contenant la chaîne @gl_introduced — un marqueur observé dans les tentatives d'exploitation connues.

Pourquoi ça concerne les éditeurs SaaS, pas seulement les équipes DevOps

Cette faille touche l'infrastructure de développement (GitLab auto-hébergé), pas directement une application SaaS grand public — mais elle illustre un pattern qu'on retrouve constamment dans les audits d'API GraphQL : une directive ou un champ de requête censé être réservé à un usage interne ou administratif n'est pas correctement isolé de l'accès public. Le même défaut de conception (validation insuffisante des directives et champs GraphQL exposés) se retrouve régulièrement dans les API GraphQL d'applications métier, avec des conséquences similaires : modification ou suppression de données sans authentification.

Ce qu'il faut faire

Ce que CleanIssue vérifie

Lors d'un audit d'API, nous testons systématiquement les endpoints et directives GraphQL pour vérifier qu'aucune opération de modification ou suppression n'est accessible sans authentification appropriée — exactement le type de défaut exploité ici.

À retenir