GitLab CVE-2026-110264 : la faille critique à corriger

Le 21 octobre 2026, GitLab a publié un correctif critique noté 10.0 sur 10 : CVE-2026-110264. La faille permet à un attaquant non authentifié d'exécuter du code sur un serveur GitLab auto-hébergé, et elle concerne toutes les versions depuis GitLab 7.0, sortie en 2014. ^1

Je suis CTO hands-on : j'architecture, je code, je structure l'équipe technique. Un GitLab auto-hébergé est souvent le serveur le moins surveillé d'une entreprise, alors qu'il contient tout : le code source, les secrets de CI/CD, les clés de déploiement. Cette semaine, avec PHP2Shell et Node2Shell, c'était la troisième faille majeure publiée le même jour. Voici ce qu'il faut savoir sur celle-ci, et pourquoi elle pose une question plus large que le simple patch.

En bref : ce qu'il faut retenir sur CVE-2026-110264

• Quoi : un dépassement d'entier (integer overflow) lors de la compilation d'une expression régulière spécialement construite, qui permet à un utilisateur non authentifié d'exécuter du code sur le serveur GitLab. ^1
• Gravité : 10.0 en CVSS 3.1, le score maximal. ^1
• Qui est concerné : GitLab Community Edition et Enterprise Edition auto-hébergés, de la version 7.0 aux versions corrigées. GitLab.com et GitLab Dedicated sont déjà corrigés. ^1
• Versions corrigées : 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 et 18.11.13. ^1
• Piège : si vous avez patché le 12 octobre pour CVE-2026-97229, vous êtes de nouveau vulnérable. ^2
• Exploitation : aucune exploitation dans la nature confirmée au 22 octobre, faille absente du catalogue KEV de la CISA. ^3
• Action : mettre à jour. GitLab ne propose aucun contournement. ^1

Ce qu'est cette faille, sans jargon

GitLab est écrit en Ruby. Pour traiter les expressions régulières, Ruby utilise un moteur appelé Onigmo, que GitLab embarque dans ses paquets. La faille se trouve dans ce moteur : en compilant une expression régulière construite sur mesure, un compteur interne dépasse sa capacité, ce qui permet une écriture en mémoire hors limites, puis une exécution de code. ^1

GitLab n'a pas publié le chemin d'exploitation complet, pour laisser le temps aux administrateurs de patcher. Une analyse indépendante publiée par Lilting décrit un point d'entrée plausible : le rendu des fichiers .org (le format Org mode). La librairie qui affiche ces fichiers transmet certains mots-clés au moteur d'expressions régulières sans les échapper. Celui qui écrit le fichier contrôle donc l'expression régulière compilée par le serveur. Selon cette analyse, l'exécution de code se fait avec l'utilisateur système git, celui qui fait tourner GitLab. ^4

Si cette analyse se confirme, la conséquence est sérieuse : un simple affichage de fichier peut suffire. Ce n'est pas une fonctionnalité d'administration obscure qu'on peut désactiver, c'est le cœur de ce que fait une forge de code.

Pourquoi c'est plus grave qu'une faille sur un serveur web

Un attaquant qui exécute du code sur votre serveur web accède à une application. Un attaquant qui exécute du code sur votre GitLab, avec l'utilisateur git, accède potentiellement à :

• tout votre code source, y compris les dépôts privés ;
• les variables CI/CD, où se trouvent souvent les clés d'API, les accès cloud et les mots de passe de base de données de production ;
• les clés de déploiement et les tokens d'accès aux registres de conteneurs ;
• vos pipelines, ce qui permet d'injecter du code dans ce que vous livrez en production.

C'est ce dernier point qui me préoccupe le plus. Une forge de code compromise, ce n'est pas seulement une fuite de données, c'est une attaque de la chaîne d'approvisionnement : le code malveillant part en production par votre propre pipeline, signé par vos propres outils. C'est aussi pour ça que l'analyse publiée sur DEV Community recommande de faire tourner les secrets de CI après avoir patché. ^2

Trois failles critiques en un mois

Les trois failles touchent le même moteur d'expressions régulières. Conséquence pratique : une instance mise à jour le 12 octobre est de nouveau vulnérable, et il faut patcher une deuxième fois. ^2 Il est raisonnable de penser que ce moteur va continuer à être examiné de près dans les semaines qui viennent.

Quelles versions de GitLab sont vulnérables ?

Source : note de version officielle de GitLab. ^1

Pour les instances en 18.10 ou antérieures, il n'y a pas de correctif sur votre branche : il faut suivre les étapes de montée de version obligatoires de GitLab jusqu'à une version corrigée. ^4 Sur une instance très ancienne, cela peut représenter plusieurs mises à jour successives.

Le plan d'action que j'applique

1. Vérifier la version exacte

Ne vous fiez pas à la date de votre dernière maintenance, comparez la version exacte avec le tableau ci-dessus. ^2 Sur une installation Omnibus :

sudo gitlab-rake gitlab:env:info

La version est aussi visible dans l'interface, sur la page /help de votre instance.

2. Mettre à jour

GitLab recommande une mise à jour immédiate de toutes les instances auto-hébergées. Deux points à anticiper : ^1

• la mise à jour inclut des migrations de base de données. Une instance mono-serveur subira une interruption pendant la mise à jour, une instance multi-nœuds peut suivre la procédure sans interruption ;
• faites une sauvegarde avant, comme pour toute mise à jour de GitLab.

Si vous avez installé GitLab depuis les sources avec le Ruby du système, et non via les paquets Omnibus ou l'image Docker officielle, la mise à jour de GitLab ne suffit pas : le correctif porte sur le Ruby embarqué par GitLab. Selon Lilting, le correctif côté Ruby n'était pas encore disponible dans une version publiée au moment de son analyse. ^4 Dans ce cas, passer à l'installation Omnibus est la voie la plus sûre.

3. Réduire l'exposition si vous ne pouvez pas patcher tout de suite

GitLab ne publie aucun contournement, et aucun réglage connu ne permet de désactiver uniquement le rendu des fichiers Org. ^4 La seule mesure qui réduit vraiment le risque en attendant est de retirer l'instance d'Internet : accès uniquement via VPN, ou derrière un proxy d'authentification. Ce n'est pas un correctif, mais une instance accessible uniquement par vos équipes n'est plus exposée à un attaquant anonyme.

C'est d'ailleurs une configuration que je recommande de façon permanente pour un GitLab auto-hébergé dans une startup : il y a très peu de bonnes raisons de l'exposer publiquement.

4. Chercher des traces d'exploitation

GitLab a publié deux règles de détection pour les instances auto-hébergées : « Onigmo native worker crash » et « Org mode render error burst ». ^1 D'après l'analyse de Lilting, sur une installation Omnibus, cela correspond à : ^4

• dans exceptions_json.log, des erreurs Timeout::Error lors du rendu de fichiers .org, répétées cinq fois ou plus depuis un même client en 30 minutes ;
• dans puma_stderr.log, un rapport [BUG] de Ruby qui mentionne org-ruby ou des fonctions d'Onigmo comme match_at ;
• dans les logs Sidekiq (/var/log/gitlab/sidekiq/current), des plantages de workers, pour les variantes qui passent par la CI/CD.

La même analyse précise que la plupart des tentatives échouent, et qu'une tentative réussie peut ne laisser aucune trace. L'absence de signal ne prouve donc rien.

5. Faire tourner les secrets si l'instance était exposée

Si votre GitLab était accessible depuis Internet sans correctif, considérez que les secrets qu'il contient ont pu être lus : variables CI/CD, tokens de déploiement, clés SSH de déploiement, accès aux registres et aux comptes cloud. ^2 C'est fastidieux, mais c'est nettement moins coûteux que de découvrir trois mois plus tard qu'une clé AWS a servi à miner de la cryptomonnaie.

Les autres failles corrigées dans la même version

La version du 21 octobre corrige aussi onze autres failles. Les plus importantes pour une startup : ^1

• CVE-2026-15723 (8.2) : prise de contrôle d'un compte LDAP existant via le lien automatique OmniAuth SAML et LDAP, quand les deux sont activés.
• CVE-2026-112212 (7.5) : empoisonnement du cache des documents de découverte OAuth/OIDC, qui peut rediriger les flux d'authentification vers un serveur externe.
• CVE-2026-105777 (4.3) : un utilisateur non authentifié peut récupérer des identifiants internes du serveur à cause d'en-têtes de réponse mal filtrés.

La vraie question : faut-il encore héberger son propre GitLab ?

C'est une question à se poser lors de tout audit technique, et cette semaine lui donne un relief particulier. GitLab.com était déjà corrigé au moment de l'annonce. ^1 Les clients auto-hébergés, eux, ont dû patcher deux fois en neuf jours pour des failles notées 10.0.

Héberger son GitLab a des raisons valables : contraintes réglementaires, données sensibles, exigences contractuelles de certains clients, coûts à grande échelle. Mais dans beaucoup de startups, la raison réelle est historique : quelqu'un l'a installé il y a quatre ans, et personne n'est clairement responsable de sa maintenance.

Mon critère est simple : si personne dans l'équipe n'a dans son périmètre la mise à jour de GitLab sous 48 heures après un correctif critique, l'auto-hébergement est un risque, pas une économie. Soit on désigne un responsable et on automatise les mises à jour, soit on passe sur une offre hébergée. C'est une décision d'architecture comme une autre, qui doit se prendre en regardant le coût réel de maintenance, pas seulement le prix de la licence.

C'est typiquement le genre d'arbitrage qu'un audit technique met sur la table en quelques jours, et que je porte ensuite dans la durée en CTO à temps partiel : décider, puis faire moi-même la migration ou la mise en place des mises à jour automatiques.

FAQ : la faille GitLab CVE-2026-110264

Qu'est-ce que la faille CVE-2026-110264 ?

CVE-2026-110264 est une vulnérabilité critique de GitLab, notée 10.0 en CVSS 3.1, corrigée le 21 octobre 2026. Un dépassement d'entier dans le moteur d'expressions régulières Onigmo, utilisé par le Ruby embarqué dans GitLab, permet à un attaquant non authentifié d'exécuter du code sur le serveur. Elle concerne toutes les instances auto-hébergées depuis GitLab 7.0.

GitLab.com est-il concerné ?

Non. GitLab.com était déjà corrigé au moment de l'annonce, de même que les instances GitLab Dedicated en version 19.3.5-internal0, 19.4.2-internal0 ou ultérieure. Seules les instances auto-hébergées, Community Edition et Enterprise Edition, doivent être mises à jour par leurs administrateurs.

J'ai déjà mis à jour GitLab le 12 octobre, suis-je protégé ?

Non. Le correctif du 12 octobre concernait une autre faille, CVE-2026-97229. CVE-2026-110264 passe par un autre point d'entrée et touche aussi les versions publiées le 12 octobre. Il faut monter en 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 ou 18.11.13 selon votre branche.

Existe-t-il un contournement en attendant la mise à jour ?

GitLab n'en publie aucun. La seule mesure de réduction du risque est de retirer l'instance d'Internet, en limitant l'accès à un VPN ou à un proxy d'authentification. Ce n'est pas une correction : la mise à jour reste nécessaire.

La faille est-elle exploitée activement ?

Au 22 octobre 2026, GitLab ne signalait aucune exploitation et la faille ne figurait pas au catalogue KEV de la CISA. Des dépôts GitHub présentés comme des preuves de concept ont été référencés le 23 octobre, sans vérification indépendante. ^5 Pour une faille notée 10.0 et exploitable sans authentification, l'absence d'exploitation confirmée ne doit pas retarder le patch.

Faut-il changer ses secrets de CI/CD ?

Si votre instance était accessible depuis Internet sans correctif, oui. Une exécution de code avec l'utilisateur git donne potentiellement accès aux variables CI/CD, aux tokens de déploiement et aux clés d'accès cloud. Faire tourner ces secrets après la mise à jour est la mesure prudente.

Ce que je recommande, en tant que CTO hands-on

Vérifiez la version exacte de votre GitLab aujourd'hui, et mettez-le à jour même si vous l'avez fait il y a deux semaines. Si l'instance est exposée sur Internet, placez-la derrière un VPN et faites tourner vos secrets de CI. Puis prenez le temps de répondre honnêtement à une question : qui, chez vous, est responsable de ce serveur ?

Cette semaine, PHP, Node.js et GitLab ont publié des correctifs critiques le même jour. Les équipes qui s'en sont sorties sans stress n'avaient pas forcément les meilleurs outils : elles savaient simplement ce qui tournait où, et qui devait s'en occuper.

Sources et références

• GitLab, Critical Patch Release 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13
• DEV Community, GitLab's second perfect score in nine days
• SOC Prime, CVE-2026-110264 : Critical GitLab RCE Vulnerability
• Lilting, GitLab CVE-2026-110264 Lets Unauthenticated Attackers Run Code by Rendering an .org File
• Sploitus, référencement d'une preuve de concept pour CVE-2026-110264