veilletech.fr
22 août Feed du jour
#02 GITLAB Article

GitLab : faille 9,4 exploitée en quelques jours

Attendre le prochain cycle de correctifs n'est plus une option défendable.

CVE-2026-19478, une injection de code notée 9,4 dans GitLab CE et EE, est exploitée quelques jours après sa divulgation. Un attaquant non authentifié peut modifier ou supprimer des projets publics, réécrire leurs données, forger des enregistrements de fusion et bannir les mainteneurs. watchTowr dit l'avoir reproduite en quelques minutes et observée sur ses pots de miel.

2 min de lecturevidéo 1:24
Partager
Sommaire6 sections
  1. Ce qui se passe
  2. Les versions concernées
  3. Pourquoi l'impact dépasse la suppression
  4. Le vrai signal : le délai
  5. Ce qu'il faut faire maintenant
  6. À retenir

Ce qui se passe

CVE-2026-19478, une injection de code notée 9,4 sur l'échelle CVSS, est activement exploitée dans GitLab. La société watchTowr, spécialisée dans la gestion d'exposition, rapporte avoir observé des tentatives contre son réseau de pots de miel quelques jours seulement après la divulgation publique.

La faille s'exploite via une directive GraphQL. Elle permet à un attaquant non authentifié de modifier ou de supprimer des projets publiquement accessibles et de réécrire leurs données — sans identifiants, sans interaction d'un utilisateur, et sans configuration exotique côté victime.

Les versions concernées

Community Edition comme Enterprise Edition :

Branche Corrigé à partir de
18.2 18.11.11
19.0 19.0.8
19.1 19.1.6
19.2 19.2.4

Les instances auto-hébergées exposées sur Internet sont la cible prioritaire. Une instance GitLab derrière un VPN reste concernée par la mise à jour, mais pas par l'urgence.

Pourquoi l'impact dépasse la suppression

Effacer un dépôt est bruyant : on s'en aperçoit, et on restaure une sauvegarde. Ce que décrit watchTowr est plus insidieux. Un attaquant peut aussi :

C'est la confiance dans l'historique qui est visée, pas seulement la disponibilité du code. Un dépôt dont l'historique de merge ment est un dépôt dont plus aucune revue n'a de valeur.

Le vrai signal : le délai

Le point souligné par Jake Knott, chercheur principal chez watchTowr, mérite d'être retenu au-delà de cette faille précise : son équipe dit avoir reproduit la vulnérabilité en quelques minutes après sa publication.

Le raisonnement classique — « on patchera au prochain cycle de maintenance » — supposait un délai de plusieurs semaines entre divulgation et exploitation de masse. Ce délai se compresse, et l'outillage assisté par modèles de langage y contribue directement : reproduire un correctif public pour en déduire l'exploit est devenu une tâche de quelques minutes plutôt que de quelques jours.

Ce qu'il faut faire maintenant

  1. Mettre à jour vers 19.2.4, 19.1.6, 19.0.8 ou 18.11.11 selon votre branche.
  2. Si le correctif ne peut pas être appliqué immédiatement, restreindre l'accès non authentifié à /api/graphql, ou couper l'accès public aux dépôts.
  3. Chercher les traces. watchTowr recommande de fouiller les journaux web à la recherche de requêtes contenant @gl_introduced, marqueur des sondes et tentatives d'exploitation.