GitLab : la CVE-2026-19478 exploitée activement quelques jours après sa divulgation

La vulnérabilité CVE-2026-19478 de GitLab a été observée en conditions réelles quelques jours seulement après sa divulgation publique. La détection remonte au 21 août 2026 et a été effectuée par watchTowr, qui a identifié des tentatives visant son propre réseau de honeypots.

L’entreprise a déclaré avoir reproduit le problème quelques minutes après sa divulgation. Cette faille permet à un attaquant distant et non authentifié d’intervenir sur des projets GitLab accessibles publiquement, sans identifiants ni interaction de la part des utilisateurs.

Une injection de code via GraphQL

La faille concerne une directive GraphQL et est classée comme une injection de code, avec la référence CWE-94. Dans certaines conditions, une requête spécialement conçue peut permettre de modifier ou de supprimer des projets ainsi que les données associées.

La description publiée par la NVD confirme que l’attaque peut être menée à distance contre des projets publics et des données utilisateur. Aucun privilège préalable n’est requis et la complexité de l’attaque est considérée comme faible.

Le score CVSS v3 est de 9,4 :

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

L’impact sur la confidentialité est jugé faible, mais l’intégrité et la disponibilité peuvent être fortement compromises. En pratique, l’attaquant pourrait modifier des contenus et des configurations, voire rendre indisponibles des composants essentiels des projets.

Référentiels supprimés et fusions falsifiées

Selon watchTowr, les conséquences ne se limitent pas à la modification de données isolées. Une exploitation réussie peut notamment permettre :

• la suppression de référentiels entiers ;
• la modification des données des projets ;
• la falsification des enregistrements de fusion ;
• l’exclusion ou le blocage des mainteneurs ;
• l’affichage trompeur d’un correctif comme intégré alors qu’il ne l’a jamais été.

La falsification des enregistrements de fusion est particulièrement préoccupante, car elle peut compromettre la confiance dans les processus de développement. Un projet peut indiquer qu’une modification a déjà été intégrée alors que le code corrigé n’a pas réellement été appliqué ou vérifié.

Le problème concerne surtout les instances exposées sur Internet, disposant de référentiels publics et de fonctionnalités GraphQL accessibles depuis l’extérieur. Aucun groupe criminel n’a été désigné comme responsable des attaques observées.

Versions GitLab concernées

Les deux éditions GitLab Community Edition (CE) et Enterprise Edition (EE) sont vulnérables.

Les versions concernées sont :

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

GitLab a corrigé la faille dans les versions suivantes :

• 18.11.11 ;
• 19.0.8 ;
• 19.1.6 ;
• 19.2.4.

Les administrateurs doivent vérifier la branche utilisée et appliquer la version correspondante, sans se contenter de contrôler le numéro de version principal. Une instance exécutant une version antérieure au correctif reste exposée.

La rapidité de l’exploitation réduit la marge de manœuvre

La chronologie observée par watchTowr montre un délai très court entre la divulgation et les activités d’exploitation. Jake Knott, principal security researcher de l’entreprise, a associé cette rapidité à l’utilisation d’outils et de processus reposant sur l’intelligence artificielle.

Il s’agit d’une observation concernant l’accélération des activités offensives, et non de l’attribution à un acteur précis. Le constat opérationnel est néanmoins clair : après la publication des détails techniques, la fenêtre disponible pour mettre les systèmes à jour peut être très réduite.

Selon les informations disponibles, la vulnérabilité ne figure pas dans le catalogue CISA KEV. Aucune échéance CISA associée n’est donc disponible. Cette absence du catalogue ne diminue toutefois pas la priorité de l’intervention : l’exploitation in-the-wild a été observée directement par watchTowr.

Mettre GitLab à jour et contrôler les journaux

La principale mesure consiste à mettre à jour les instances CE ou EE vers les versions corrigées : 18.11.11, 19.0.8, 19.1.6 ou 19.2.4, selon la branche installée.

Si une mise à jour immédiate est impossible, GitLab recommande d’adopter l’une des mesures d’atténuation suivantes :

• limiter l’accès non authentifié au point de terminaison /api/graphql ;
• supprimer complètement l’accès aux référentiels publics.

Ces mesures réduisent la surface d’exposition, mais ne remplacent pas la correction logicielle. Après la mise à jour, il convient de vérifier que les restrictions temporaires ne sont retirées qu’une fois le risque effectivement maîtrisé.

Les organisations n’ayant pas encore appliqué les correctifs devraient examiner les journaux web à la recherche de requêtes contenant :

@gl_introduced

Le contrôle doit également couvrir les indicateurs de balayage, de probing et de tentatives d’exploitation. Il faut comparer les modifications récentes apportées aux référentiels, aux données des projets, aux enregistrements de fusion et aux autorisations des mainteneurs.

Toute modification non autorisée, disparition de référentiels, suppression de mainteneurs ou fusion inattendue doit entraîner une vérification des comptes concernés, des journaux applicatifs et des sauvegardes. En présence de modifications suspectes, il ne suffit pas de restaurer le référentiel : il faut également contrôler les métadonnées, les autorisations et l’historique des opérations.