GitLab corrige une faille critique qui laisse modifier tes projets publics

GitLab a publié une mise à jour de sécurité critique pour ses versions auto-hébergées. Une faille d'injection de code, notée 9,4 sur 10, permet à un attaquant sans aucun compte de modifier ou de supprimer des projets publics et des données d'utilisateurs. Voici ce qu'il faut savoir, et surtout ce qu'il faut faire.

Une faille qui ne demande aucune connexion

La vulnérabilité, référencée CVE-2026-19478, touche GitLab Community Edition (CE) et Enterprise Edition (EE). Elle passe par une directive GraphQL, un langage de requête utilisé par l'interface de GitLab pour dialoguer avec le serveur. En envoyant une requête spécialement construite, un attaquant peut injecter du code et l'exécuter à distance, sans authentification ni interaction de l'utilisateur.

Le score CVSS de 9,4 sur 10 en dit long sur la gravité. Concrètement, un pirate qui exploite la faille peut modifier ou effacer des projets publics hébergés sur l'instance, ainsi que des données d'utilisateurs. Pour une plateforme qui sert de dépôt de code à des équipes entières, c'est le scénario catastrophe : du code source, des issues et des historiques peuvent disparaître en quelques requêtes.

Capture d'écran de l'interface GitLab illustrant la faille d'injection de code

Source : Help Net Security — capture de l'interface GitLab.

Qui est concerné, et qui ne l'est pas

Les versions concernées vont de la 18.2 à la 19.2, avec des correctifs précis : 18.11.11, 19.0.8, 19.1.6 et 19.2.4. Si vous hébergez votre propre instance GitLab, vous êtes dans la ligne de mire. GitLab recommande de passer immédiatement à l'une de ces versions corrigées.

En revanche, les clients de GitLab.com et de GitLab Dedicated n'ont rien à faire : les versions hébergées par GitLab sont déjà corrigées. La faille ne concerne que les installations auto-hébergées, celles que des entreprises et des particuliers font tourner sur leurs propres serveurs.

Une seconde faille, moins grave mais à ne pas négliger

La même mise à jour corrige une deuxième vulnérabilité, CVE-2026-19650, notée 7,1 sur 10. Il s'agit d'une faille de type cross-site request forgery (CSRF) dans le gestionnaire de requêtes GraphQL multiplexées. Elle permet d'exécuter des mutations via des requêtes GET, mais nécessite une interaction de l'utilisateur. Moins critique, elle mérite tout de même d'être corrigée en même temps.

Ce que tu dois faire maintenant

Si tu administres une instance GitLab auto-hébergée, la marche à suivre est simple : mets à jour vers la version corrigée dès que possible. GitLab précise que ces versions n'incluent pas de nouvelles migrations et ne devraient pas nécessiter d'arrêt pour les déploiements multi-nœuds. Pour les installations Omnibus, la mise à jour s'occupe des migrations et du redémarrage automatiquement.

C'est un rappel de plus que l'auto-hébergement a un coût caché : celui de la maintenance de sécurité. Une instance à jour est une instance qui dort tranquille. Une instance oubliée est une porte ouverte. Comme on le voyait déjà avec la faille critique de Zimbra exploitée en début de semaine, les serveurs de messagerie et de code sont des cibles de choix pour les attaquants.