veilletech.fr
27 sept. Feed du jour
#02 SÉCURITÉ Faille

GitLab : une regex dans la CI exécute du code

Une regex de trop, et c'est le serveur qui obéit.

GitLab 19.4.1, 19.3.3 et 19.2.7 corrigent deux failles critiques notées 9,9 : une regex forgée dans une configuration CI/CD suffit à un utilisateur authentifié pour exécuter du code sur le serveur. Neuf autres failles sont fermées, dont une XSS dans le diff des merge requests. Les installations auto-hébergées doivent migrer, avec une coupure sur les instances à nœud unique.

3 min de lectureintermédiairevidéo 1:18
Partager
Sommaire5 sections
  1. Ce qui se passe
  2. Les deux failles critiques
  3. Les neuf autres
  4. Comment s'y prendre
  5. À retenir

Ce qui se passe

GitLab a publié le 23 septembre les versions 19.4.1, 19.3.3 et 19.2.7 de ses éditions Community et Enterprise. Elles ferment onze failles, dont deux critiques notées 9.9, et l'éditeur demande une mise à jour immédiate des installations auto-hébergées. GitLab.com tourne déjà sur la version corrigée ; les clients GitLab Dedicated n'ont rien à faire.

Les deux failles critiques

Elles se déclenchent au même endroit : une expression régulière forgée, placée dans une configuration CI/CD, que le serveur analyse ou compile.

CVE Défaut CVSS
CVE-2026-89078 double libération de mémoire dans l'analyseur de regex 9.9
CVE-2026-93577 dépassement d'entier dans le compilateur de regex 9.9

Dans les deux cas, un utilisateur authentifié obtient l'exécution de code arbitraire sur le serveur GitLab. Versions touchées : 19.2 avant 19.2.7, 19.3 avant 19.3.3, 19.4 avant 19.4.1. Les deux ont été signalées par joaxcar via le programme HackerOne de GitLab.

L'authentification requise protège peu sur une forge : sur la plupart des instances, tout compte autorisé à créer un projet peut écrire un .gitlab-ci.yml. Et le serveur concentre ce qu'il y a de plus sensible : variables de CI, jetons, code de tous les projets.

Les neuf autres

Comment s'y prendre

  1. Relever la version en service :
Terminal
sudo gitlab-rake gitlab:env:info
  1. Passer en 19.4.1, 19.3.3 ou 19.2.7 selon la branche suivie.
  2. Prévoir l'arrêt : le correctif embarque des migrations de base. Une instance à nœud unique reste indisponible pendant qu'elles tournent ; une installation multi-nœuds peut suivre la procédure de mise à jour sans interruption. 19.3.3 et 19.2.7 ajoutent des migrations post-déploiement.

Côté Omnibus, les branches 19.3 et 19.2 passent aussi PostgreSQL en 17.11.

Source : patch release GitLab 19.4.1, 19.3.3 et 19.2.7, GitLab, 23 septembre 2026. Repéré dans la revue Developer-Häppchen de heise Developer (en allemand), 26 septembre.