GitLab publie un patch d'urgence pour la vulnérabilité GraphQL non authentifiée CVSS 9.4

Marcus Chen Staff Engineer (Backend & Cloud), YuSMP Group · Sécurité backend, cloud et plateforme pour les produits US et EU

En bref

Ce qu'est CVE-2026-19478

L'API GraphQL de GitLab accepte des payloads de directives qui indiquent au serveur comment traiter une requête. Dans les versions 18.2 à 19.2, une directive spécialement malformée peut contourner l'autorisation sur des mutations qui écrivent ou suppriment des données de projets publics — sans aucune authentification. Le score CVSS de 9.4 traduit trois facteurs : l'attaque est accessible via le réseau, ne nécessite aucune authentification, et aucune interaction de l'utilisateur victime n'est nécessaire.

Le périmètre concerne les projets publics et les données utilisateurs, non les dépôts privés protégés par authentification. Cette distinction compte pour la priorisation, mais ne réduit pas l'urgence pour les équipes hébergeant des projets open source publics, des démonstrations clients ou toute instance avec visibilité publique activée. L'historique du code, les issues, les fichiers de configuration CI et les métadonnées associées sont tous modifiables ou supprimables par l'attaquant non authentifié.

La vulnérabilité associée, CVE-2026-19650, exploite un mécanisme différent : l'endpoint multiplex GraphQL de GitLab accepte plusieurs opérations groupées en une seule requête, et la protection CSRF ne s'applique pas lorsque les opérations sont transmises via HTTP GET. Un attaquant peut créer un lien ou intégrer une requête sur n'importe quelle page visitée par la cible, et le navigateur de la victime exécute une mutation en son nom. CVSS 7.1 traduit qu'une interaction utilisateur est nécessaire, mais l'impact final est identique à CVE-2026-19478.

Qui est concerné et que faire

Le tableau ci-dessous couvre la plage complète affectée et le correctif pour chaque branche :

Les mises à jour sans interruption sont supportées pour les déploiements GitLab multi-nœuds, de sorte que les environnements de production avec capacité de mise à jour progressive peuvent patcher sans planifier de fenêtre de maintenance. Les instances mono-nœud nécessiteront un bref redémarrage. Les chemins de mise à jour sont documentés dans le guide de mise à jour standard de GitLab.

Si le patch est réellement impossible aujourd'hui (gel des changements, long processus de release), le contrôle intérimaire consiste à désactiver la visibilité publique des projets au niveau de l'instance : Zone d'administration → Paramètres → Général → Visibilité et contrôles d'accès → définir la visibilité par défaut des projets sur Privé et empêcher les membres de la modifier. Il s'agit d'une mesure d'urgence perturbatrice, pas d'un correctif — mettez à jour dès que possible.

La leçon GraphQL pour vos propres produits

Les deux CVE partagent un pattern à la racine qu'il vaut la peine d'intégrer si votre équipe construit des API GraphQL : les contrôles d'autorisation et CSRF doivent être appliqués au niveau de la couche d'exécution des requêtes, pas uniquement au niveau des résolveurs ou du middleware HTTP. Le traitement des directives en particulier est un chemin d'exécution facile à sous-tester, car il opère avant la logique des résolveurs et sort du modèle mental typique qu'appliquent la plupart des développeurs lors de l'écriture de tests.

Si votre produit expose une API GraphQL — surtout avec accès public aux requêtes — les questions immédiates sont : votre pipeline de traitement des directives applique-t-il une autorisation ? Votre endpoint multiplex valide-t-il le CSRF pour les opérations changeant d'état quelle que soit la méthode HTTP ? Ce ne sont pas des préoccupations exotiques ; ce sont exactement les lacunes qui ont produit deux CVE critiques dans une plateforme de production utilisée par des centaines de milliers d'organisations. Un audit de sécurité de votre couche API est le moyen le plus fiable de répondre à ces questions avant qu'un chercheur extérieur — ou un attaquant — ne le fasse à votre place.

Ce que cela signifie pour le marché français

GitLab est la plateforme CI/CD et de gestion du code source privilégiée par une grande partie des équipes d'ingénierie européennes et américaines de taille intermédiaire, et particulièrement pour celles qui ont besoin d'un déploiement on-premises ou en cloud privé pour des raisons de conformité ou de résidence des données. Cette préférence est précisément la raison pour laquelle une vulnérabilité écriture/suppression sans authentification dans l'API est un problème d'ordre supérieur : les équipes les plus susceptibles d'exploiter GitLab autogéré sont celles qui ont les raisons les plus strictes de protéger leur contenu.

La priorité pratique : si votre instance GitLab est exposée sur Internet, il s'agit d'une tâche du jour même. Si elle est derrière un VPN sans projet public, vous devez néanmoins patcher dans ce sprint — CVSS 9.4 ne reste pas dans un backlog. Si un gel des changements bloque la mise à jour, appliquez le verrouillage de la visibilité publique décrit ci-dessus et documentez le contrôle compensatoire dans votre registre des risques.

Ce qu'il faut faire aujourd'hui

1. Recenser toutes les instances GitLab autogérées. Les installations GitLab fantômes sont fréquentes dans les organisations ayant grandi par acquisition ou autonomie d'équipe. On ne peut patcher que ce que l'on connaît.
2. Vérifier le numéro de version de chaque instance. Zone d'administration → Aide ou l'API GitLab GET /api/v4/version retourne la version actuelle. Tout résultat compris entre 18.2 et 19.2.3 (inclus) nécessite le patch du jour.
3. Prioriser les instances exposées sur Internet. Toute instance GitLab accessible depuis l'Internet public ou depuis un segment réseau non contrôlé par votre organisation doit être traitée comme une tâche de mise à jour P0.
4. Appliquer la version corrigée pour votre branche. Suivre le chemin de mise à jour documenté par GitLab pour votre version actuelle ; ne pas sauter de versions majeures. La mise à jour sans coupure s'applique aux configurations multi-nœuds.
5. Si le patch est bloqué, restreindre la visibilité des projets publics. Zone d'administration → Paramètres → Général → Visibilité et contrôles d'accès. Documenter cela comme contrôle compensatoire temporaire.
6. Examiner les journaux d'audit pour détecter une activité GraphQL anormale. Vérifier les suppressions inattendues, les modifications de paramètres de projet ou les mutations en masse sur des projets publics dans les jours précédant la découverte de ce bulletin.
7. Confirmer la mise à jour. Après l'upgrade, appeler GET /api/v4/version et vérifier que le numéro de version correspond à la version corrigée.

Questions fréquentes

Sources

GitLab — Patch Release : 19.2.4, 19.1.6, 19.0.8, 18.11.11, 17 août 2026 (source primaire)
IT-Boltwise — GitLab stopft kritische GraphQL-Schwachstelle (couverture indépendante)
CyberSecurityNews — GitLab Patches Critical Security Vulnerabilities