GitLab corrige une faille critique de GraphQL pouvant modifier ou supprimer des projets

Une vulnérabilité critique dans les instances self-managed

GitLab a publié le 17 août 2026 une mise à jour de sécurité exceptionnelle, cinq jours après la précédente version régulière. Le correctif résout deux vulnérabilités dans les éditions Community Edition (CE) et Enterprise Edition (EE), avec un impact différent, mais toutes deux liées à l’utilisation de GraphQL.

La plus grave est CVE-2026-19478, classée Critical par GitLab avec un score CVSS de 9.4. Dans certaines conditions, un attaquant distant non authentifié pourrait modifier ou supprimer des projets publics et des données utilisateur au moyen d’une directive GraphQL.

L’entreprise n’a pas précisé quelle directive était concernée ni quelles conditions étaient nécessaires à la réussite de l’attaque. Le vecteur CVSS indique toutefois une attaque réalisable via le réseau, sans identifiants ni interaction de la victime :

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:H

Le score reflète principalement l’impact sur l’intégrité et la disponibilité des données. L’impact sur la confidentialité est en revanche considéré comme plus limité.

Au 18 août 2026, GitLab n’avait signalé aucune exploitation de la vulnérabilité. Aucun code d’exploitation public associé à CVE-2026-19478 ne semblait non plus disponible sur GitHub. On ignore si la faille a été ajoutée au catalogue Known Exploited Vulnerabilities (KEV) de la CISA.

Le deuxième problème concerne les mutations GraphQL via GET

La deuxième faille est CVE-2026-19650, classée High et évaluée à 7.1 selon le CVSS :

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:L

La vulnérabilité réside dans une faiblesse de type Cross-Site Request Forgery (CSRF) affectant le gestionnaire des requêtes GraphQL multiplexées. Dans certaines conditions, une validation insuffisante des requêtes aurait pu permettre à un utilisateur non authentifié d’exécuter des opérations de modification, appelées mutations, au moyen de requêtes HTTP GET.

Contrairement à la faille critique, ce scénario nécessite une interaction de l’utilisateur. La victime devrait donc effectuer une action permettant à la requête préparée par l’attaquant d’être traitée par l’instance GitLab.

Le problème ne donne pas automatiquement un accès complet au serveur. Le risque concerne toutefois l’exécution non autorisée d’opérations modifiant des données, avec des conséquences potentielles sur les projets, les configurations et les ressources gérées par la plateforme. GitLab n’a pas publié suffisamment de détails pour reconstituer précisément le déroulement de l’attaque.

Les versions vulnérables et les versions corrigées

Les correctifs ont été publiés dans les versions suivantes :

• 19.2.4
• 19.1.6
• 19.0.8
• 18.11.11

Sont vulnérables :

• toutes les versions 18.2 antérieures à la 18.11.11 ;
• les versions 19.0 antérieures à la 19.0.8 ;
• les versions 19.1 antérieures à la 19.1.6 ;
• les versions 19.2 antérieures à la 19.2.4.

Les opérateurs utilisant les branches de la 18.2 à la 18.10 ne bénéficieront pas d’un correctif étendu à ces branches et doivent planifier une mise à niveau vers une version prise en charge et corrigée. Les versions installées peuvent être vérifiées depuis la page d’administration de l’instance ou au moyen des outils de gestion du paquet utilisé.

Le correctif concerne exclusivement les installations self-managed. GitLab.com et GitLab Dedicated utilisent déjà des versions corrigées : leurs clients n’ont donc aucune mise à jour manuelle à appliquer.

La mise à jour n’introduit aucune nouvelle migration et, dans les installations multinœuds, ne devrait pas nécessiter de période d’indisponibilité. Les vérifications opérationnelles habituelles restent néanmoins nécessaires, en particulier dans les environnements dotés de nœuds distribués, de proxy ou de composants GraphQL exposés via des infrastructures personnalisées.

Mesures à prendre par les administrateurs

La mesure de mitigation indiquée par GitLab consiste à effectuer la mise à jour vers l’une des quatre versions corrigées. Aucune mesure alternative équivalente n’a été communiquée, telle que la désactivation temporaire d’une directive GraphQL spécifique ou l’application d’une règle WAF suffisante pour bloquer les deux problèmes.

Les administrateurs doivent donc :

1. vérifier la version de l’instance self-managed ;
2. la mettre à jour vers 19.2.4, 19.1.6, 19.0.8 ou 18.11.11 ;
3. examiner les journaux applicatifs et d’accès à la recherche de requêtes GraphQL inhabituelles ;
4. rechercher toute modification inattendue de projets publics, dépôts, tickets, configurations et données utilisateur ;
5. vérifier la présence de requêtes GET inhabituelles associées à des opérations GraphQL modifiant des données.

Le bulletin ne fournit aucun indicateur de compromission spécifique, nom de campagne ou motif réseau déjà observé. Les journaux ne permettent donc pas nécessairement de distinguer une tentative réussie d’une activité légitime sans corréler les URL, les identités, les horaires et les modifications effectuées.

Les organisations qui ne peuvent pas appliquer immédiatement la mise à jour devraient réduire l’exposition de l’instance en limitant son accès externe selon leurs contraintes opérationnelles. Cette mesure ne remplace toutefois pas le correctif et ne garantit pas la protection si l’instance doit rester accessible depuis des réseaux non fiables.

Divulgation technique attendue dans les prochains mois

GitLab a indiqué qu’il publierait les détails des vulnérabilités sur son issue tracker 90 jours après la publication du correctif. Pour ces deux problèmes, la divulgation technique est donc attendue vers la mi-novembre 2026.

Ce calendrier n’est pas totalement cohérent avec une communication antérieure du 10 juin 2026, qui mentionnait une période de 30 jours. Jusqu’à la publication des détails, restent inconnus la directive GraphQL concernée par la faille critique, les prérequis complets de l’exploitation et les moyens permettant de contourner la validation des requêtes GET.

Cet épisode survient après un rapport publié en juillet 2026 sur une autre vulnérabilité de GitLab. Dans ce cas, les chercheurs avaient publié un code d’exploitation fonctionnel visant les serveurs self-managed. L’entreprise n’a pas répondu immédiatement à une demande de commentaire concernant cette nouvelle mise à jour.

Pour les administrateurs, la priorité reste inchangée : identifier les instances correspondant aux plages vulnérables et les mettre rapidement à niveau vers une version corrigée, sans attendre la future publication des détails techniques.