## Que s'est-il passé ?
La faille porte l'identifiant CVE-2026-110264 et obtient un score CVSS de 10,0 : exploitable à distance, sans compte, sans action de l'utilisateur, avec un impact total sur la confidentialité, l'intégrité et la disponibilité du serveur.
Le problème vient d'Onigmo, le moteur d'expressions régulières de Ruby, que GitLab embarque dans ses propres paquets. Une expression régulière spécialement conçue provoque un dépassement d'entier au moment de sa compilation. Ce débordement mémoire peut ensuite être détourné pour faire exécuter du code arbitraire au serveur.
La faille a été signalée par le chercheur joaxcar via le programme de bug bounty de GitLab. C'est sa quatrième faille d'exécution de code dans ce moteur en un mois environ. Mais c'est la première qui remonte aussi loin : GitLab 7.0, sorti en 2014.
Point important : le correctif du 12 octobre (CVE-2026-97229) ne couvrait que les versions 19.2 et suivantes. Une instance mise à jour le 12 octobre reste vulnérable tant qu'elle n'est pas passée aux nouvelles versions.
# Qui est concerné ?
Sont concernées toutes les instances GitLab auto-hébergées (Community et Enterprise Edition), installées via les paquets Omnibus ou les images de conteneur. Si vous utilisez GitLab.com, vous n'avez rien à faire : la plateforme est déjà corrigée, tout comme les instances GitLab Dedicated.
Version corrigées
- 19.5.1
- 19.4.3
- 19.3.6
- 19.2.9
- 19.1.9
- 19.0.10
- 18.11.13
GitLab a fait une exception à sa politique habituelle en rétroportant le correctif jusqu'à la branche 18.11. Si votre instance est encore plus ancienne, il faut monter au minimum en 18.11.13.
À ce jour, GitLab ne signale aucune exploitation active, et la faille ne figure pas au catalogue KEV de la CISA. Mais aucune mesure de contournement n'est proposée : la mise à jour est la seule protection.
#Pourquoi c'est sérieux
Un serveur GitLab n'est pas un serveur comme les autres. Il contient souvent tout le patrimoine logiciel d'une entreprise, et les clés qui permettent de le déployer. Un attaquant qui en prend le contrôle peut :
• voler le code source et la propriété intellectuelle qu'il contient ;
• récupérer les secrets stockés dans les variables CI/CD : clés d'API, accès cloud, mots de passe de bases de données ;
• modifier le code ou les pipelines pour glisser une porte dérobée dans les applications livrées aux clients ;
• rebondir vers les serveurs de production et le reste du réseau.
Le même correctif traite aussi onze autres failles, dont deux élevées : une prise de contrôle de compte quand SAML et l'auto-liaison LDAP sont activés (CVE-2026-15723, 8,2), et un empoisonnement de cache sur les points d'entrée OAuth/OIDC (CVE-2026-112212, 7,5).
# Que faire dès maintenant ?
1. Repérez toutes vos instances GitLab, y compris les serveurs de test, les instances oubliées et les runners associés.
2. Vérifiez la version (menu Aide ou /help) et comparez-la au tableau ci-dessus.
3. Mettez à jour vers la version corrigée de votre branche. Commencez par les instances exposées sur Internet.
4. Prévoyez une courte interruption : les versions 19.4.3 et 19.3.6 contiennent des migrations de base de données. Sur un serveur unique, GitLab sera indisponible le temps de la mise à jour ; les installations multi-nœuds peuvent suivre la procédure sans coupure.
5. Ne vous fiez pas au correctif du 12 octobre : il ne protège pas contre cette nouvelle faille.
6. Cherchez des traces d'attaque. GitLab publie deux règles de détection (« Onigmo native worker crash » et « Org mode render error burst ») à appliquer sur les journaux applicatifs.
7. En cas de doute, changez les secrets : jetons d'accès, variables CI/CD, clés SSH de déploiement.
# En résumé
Une faille 10/10, sans authentification, sur toutes les versions auto-hébergées depuis 2014, et aucun contournement possible : il faut mettre à jour, maintenant. Deux failles critiques en dix jours sur le même composant montrent aussi qu'un GitLab auto-hébergé demande un suivi des mises à jour aussi régulier qu'un serveur de production.
Vous hébergez votre propre GitLab et vous n'êtes pas sûr d'être à jour ? Notre équipe peut vérifier vos instances, appliquer le correctif et contrôler l'absence de compromission. Racontez-nous votre situation.
