GitLab CVE-2026-19478 - suppression arbitraire anonyme de projet via GraphQL
CVSS :9.4
Catégorie : Improper Control of Generation of Code (CVE-2026-19478)
Résumé
Le lundi 17 août 2026, GitLab a publié un correctif d'urgence pour la CVE-2026-19478. Signalée par le chercheur hiimguardian via le programme Bug Bounty HackerOne de GitLab, elle permet à un attaquant sans le moindre compte de modifier ou supprimer des projets publics et les données utilisateur associées, via une simple directive GraphQL.
Aucun PoC officiel n'a été publié à ce jour, et GitLab garde le détail technique sous silence. Cela n'a pas empêché les équipes de watchTowr de reproduire la faille et d'alerter, quelques jours plus tard, sur des exploitations bien réelles.
Chronologie des faits
Date | Nouvelle |
17 août 2026 | GitLab publie les correctifs (19.2.4, 19.1.6, 19.0.8, 18.11.11). |
18 août 2026 | watchTowr reproduit la faille en quelques minutes, à partir du seul advisory et du diff. |
19 août 2026 | Premières exploitations in-the-wild observées sur ses honeypots, 2 jours après la divulgation. |
~novembre 2026 | (à venir) Publication du ticket GitLab, 90 jours après le correctif. |
Versions impactées et correctifs
Branche | Versions vulnérables | Correctif (17 août 2026) |
18.x | 18.2 → antérieures à 18.11.11 | 18.11.11 |
19.0 | antérieures à 19.0.8 | 19.0.8 |
19.1 | antérieures à 19.1.6 | 19.1.6 |
19.2 | antérieures à 19.2.4 | 19.2.4 |
Le même cycle corrige également la CVE-2026-19650.
CE et EE sont toutes deux concernées. Seules les instances self-managed sont exposées : GitLab.com et GitLab Dedicated étaient déjà corrigées.
Attention aux branches 18.2 à 18.10. Elles sont dans le périmètre vulnérable mais ne reçoivent aucun correctif. Si vous tournez sur l'une d'elles, il faut migrer vers une branche patchée : le correctif que vous attendez pour votre version ne viendra pas.
Compréhension de la vulnérabilité
GitLab qualifie la faille de code injection atteignable via une directive GraphQL. Une directive est une annotation attachée à une requête pour en modifier le traitement côté serveur.
Le problème tient à un détail d'ordonnancement : elle est résolue avant les contrôles d'accès appliqués au resolver.
C'est cette antériorité qui rend la faille exploitable sans authentification. Un projet public est interrogeable sans session, et la directive agit en amont de toute vérification des droits. Résultat : un attaquant anonyme peut modifier ou supprimer des projets publics et réécrire leurs données.
Démonstration
Disclaimer Étant donné qu'aucun POC officiel n'est sorti et que GitLab n'a pas encore voulu dévoiler précisément d'où provient la vulnérabilité, les détails de l'exploitation ne seront pas dévoilés.
Pour ce lab l'image docker gitlab/gitlab-ee:19.2.2-ee.0 ainsi que l'exploit créé par Safercy ont été utilisés.
Dans la vidéo suivante, je vais démontrer la possibilité d'injection en supprimant mon projet sans être authentifié, grâce à notre exploit. Il est important de noter que le projet doit être publique
pour que cela fonctionne.
On peut voir suite à l'exécution que le projet à bien été supprimé. Voici à quoi la requête ressemble dans les logs de GitLab (Chemin des logs utilisé : /var/log/gitlab/gitlab-rails/production_json.log) :
On peut observer que la requête malicieuse ne contient ni user id ni username, car elle est non authentifiée. La requête non censurée est présente dans les journaux à cet emplacement : /var/log/gitlab/gitlab-rails/graphql_json.log.
Détection et mitigation
Si vous ne pouvez pas mettre à jour GitLab Safercy vous propose trois actions concrètes :
Restreindre l'accès non authentifié à /api/graphql.
Désactiver les dépôts publics là où c'est possible.
Chasser dans les logs les requêtes contenant @gl_introduced.
Côté logs GitLab, comme le montre la capture plus haut, la requête malicieuse se repère dans /var/log/gitlab/gitlab-rails/production_json.log à l'absence de user_id et de username, signature d'une requête non authentifiée.
Conclusion
Le plus frappant ici, c'est la vitesse des attaquants à avoir exploité la faille malgré le silence de GitLab. Aucun PoC public, une publication volontairement vague, juste en observant le "commit", les attaquants ont pu la reproduire.
Le cœur du problème est dans l'ordre des opérations, une directive GraphQL résolue avant les contrôles d'accès. Simple mais l'effet est brutal : un dépôt public devient destructible par n'importe quel visiteur anonyme.
Vérifiez la version réellement installée, en particulier sur les branches 18.2 à 18.10 qui restent vulnérables sans correctif.
L'approche Safercy
Un GitLab self-managed exposé sur Internet est rarement isolé : il concentre le code, les secrets CI/CD et les accès à toute la chaîne de build, ce qui en fait une porte d'entrée idéale vers la supply chain logicielle.
Nos équipes ont reproduit cette vulnérabilité en laboratoire afin d'en valider les conditions d'exploitation et d'intégrer les vérifications correspondantes à nos missions d'audit.
Pentest / tests d'intrusion : nous testons concrètement l'exposition de vos forges et de vos API applicatives, dont les surfaces GraphQL. Lien : https://www.safercy.com/pentest-tests-d-intrusion
Réponse à incident : en cas de modification ou suppression suspecte de projets, nous qualifions la compromission et vérifions l'intégrité de vos dépôts et pipelines. Lien : https://www.safercy.com/reponse-a-incident
Une question sur votre exposition à cette CVE ? Nos experts se tiennent à votre disposition. Contactez-nous en cas de suspicion de compromission.
Sources
GitLab :
Article SecurityAffairs :
Cyberveille.gouv :
