Faille GitLab CVE-2026-110264 : vérifier votre instance et choisir la bonne version

Cet article s'adresse aux PME et aux agences qui hébergent elles-mêmes leur GitLab, sur un serveur loué, une machine virtuelle ou un cluster Kubernetes. Le 21 octobre 2026, GitLab a publié des correctifs pour la faille CVE-2026-110264, notée 10 sur 10, qui touche presque toutes les versions auto-hébergées de GitLab CE et EE. Vous allez voir comment savoir si votre instance est concernée, quelle version installer selon votre branche, ce que la mise à jour implique et comment chercher des traces d'une tentative d'attaque. Si vous utilisez GitLab.com, vous n'avez rien à faire : GitLab indique que le service en ligne tourne déjà avec la version corrigée.

Ce que corrige la faille GitLab CVE-2026-110264, en clair

D'après le bulletin de GitLab, la faille permet, « dans certaines conditions », à un utilisateur sans compte d'exécuter du code sur le serveur GitLab. Elle vient d'un dépassement d'entier au moment où GitLab compile une expression régulière spécialement préparée. Une expression régulière est un motif de recherche dans du texte. Ici, un motif construit pour dépasser une limite de taille fait écrire le moteur en dehors de la zone mémoire prévue, ce qui peut aboutir à l'exécution de commandes.

La règle de détection publiée par l'équipe sécurité de GitLab précise le chemin : le rendu des fichiers au format Org-mode (.org), dont un mot-clé est transmis tel quel au moteur d'expressions régulières de Ruby. Les commandes s'exécuteraient alors avec les droits de l'utilisateur système git. Ce n'est donc pas une faille de l'intégration continue (CI/CD) : les failles CI qui passent par le même moteur sont d'autres CVE, corrigées dans des versions précédentes.

Pourquoi la note est si haute : il n'y a besoin ni de compte ni d'action d'un utilisateur, et le serveur GitLab contient en général tout le code de l'entreprise, les variables CI/CD et les jetons d'accès. C'est cette concentration de secrets qui fait la gravité, pas une attaque déjà constatée.

Savoir si votre GitLab auto-hébergé est concerné

Sont concernées les éditions Community (CE) et Enterprise (EE) auto-hébergées, toutes versions depuis la 7.0, jusqu'aux versions corrigées listées plus bas. Le type d'installation (paquet Omnibus, sources, chart Helm) ne change rien : le bulletin précise que, sans mention contraire, tous les types sont touchés. Les instances GitLab Dedicated en 19.3.5-internal0, 19.4.2-internal0 ou plus récentes sont déjà corrigées.

Pour connaître votre version, le plus simple est de vous connecter en administrateur et d'ouvrir la page Aide (/help), qui l'affiche en haut. Sur un serveur installé avec le paquet Omnibus, vous pouvez aussi lancer :

sudo gitlab-rake gitlab:env:info

La ligne « GitLab information » donne la version exacte, par exemple 19.4.2. Notez aussi si votre instance est accessible depuis Internet ou seulement depuis votre réseau ou un VPN. Le CERT-EU recommande de traiter en priorité les instances exposées sur Internet.

Quelle version de GitLab installer selon votre branche

GitLab a publié le 21 octobre 2026 trois versions de correctif « normales » : 19.5.1, 19.4.3 et 19.3.6. Ce sont elles qu'il faut viser si vous êtes sur une de ces branches, car elles corrigent l'ensemble du lot (voir plus bas).

Pour les branches plus anciennes, GitLab a reporté le seul correctif de la faille critique dans 19.2.9, 19.1.9, 19.0.10 et 18.11.13. Concrètement :

• si vous êtes en 19.5.x, passez en 19.5.1 ;
• en 19.4.x, passez en 19.4.3 ;
• en 19.3.x, passez en 19.3.6 ;
• en 19.2, 19.1, 19.0 ou 18.11, la version corrective de votre branche (19.2.9, 19.1.9, 19.0.10 ou 18.11.13) bouche la faille critique dès aujourd'hui ;
• sur une version plus ancienne que 18.11, il n'existe pas de correctif dans votre branche : il faut planifier une montée de version, en suivant le chemin de mise à jour officiel de GitLab.

Notre conseil (c'est une déduction, pas une consigne de GitLab) : les backports sont une solution rapide, mais ils laissent ouvertes les autres failles du lot. Ils servent à gagner du temps avant de rejoindre une branche 19.3 ou plus récente.

Ce que la mise à jour implique pour votre équipe

Le bulletin signale des migrations de base de données. Sur une instance à un seul serveur, ce qui est le cas le plus courant en PME, la mise à jour provoque une coupure, car GitLab ne redémarre qu'une fois les migrations terminées. Les versions 19.4.3 et 19.3.6 contiennent des migrations, et la 19.4.3 a aussi des migrations post-déploiement. Les instances à plusieurs nœuds peuvent suivre la procédure sans interruption.

En pratique, prévenez l'équipe, choisissez un créneau court, faites une sauvegarde GitLab et copiez à part le fichier /etc/gitlab/gitlab-secrets.json, qui n'est pas inclus dans la sauvegarde standard. Après la mise à jour, revérifiez la version sur la page /help.

Chercher des traces de tentative dans les journaux

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 ». La première repère un plantage du processus Puma (le serveur web de GitLab) dont la trace passe par la bibliothèque org-ruby ou par Onigmo, le moteur d'expressions régulières de Ruby. La seconde surveille une rafale d'erreurs au rendu de fichiers .org.

Sans outil de supervision, la règle donne une recherche directe. Sur une installation Omnibus :

grep -B1 -A20 '\[BUG\]' /var/log/gitlab/puma/puma_stderr.log* \
  | grep -E 'org-ruby|headline\.rb|match_at|onig_search_gpos|onig_compile'

Une ligne trouvée ici doit être traitée comme une tentative d'exécution de code. Attention à l'inverse : la règle précise qu'une exploitation réussie est discrète et ne fait pas forcément planter quoi que ce soit. L'absence de résultat ne prouve donc pas que rien ne s'est passé. GitLab conseille aussi de regarder les fichiers appartenant à git dans /tmp, les processus inattendus lancés par Puma ou Sidekiq, les connexions sortantes, et les tâches cron ou clés SSH modifiées de l'utilisateur git.

Si vous trouvez des signes d'exécution de code, considérez l'instance comme compromise : conservez les journaux, puis changez les secrets de gitlab-secrets.json, toutes les variables CI/CD, les jetons des runners et les jetons d'accès.

Les onze autres failles corrigées dans le même lot

Le bulletin corrige onze autres failles : deux élevées, cinq moyennes et quatre faibles. La plus notable est CVE-2026-15723 (note 8,2) : lorsque l'auto-liaison entre OmniAuth SAML et LDAP est activée, un utilisateur connecté pouvait prendre le contrôle d'un compte LDAP existant. Elle concerne les versions depuis la 10.1 et n'est corrigée que dans 19.5.1, 19.4.3 et 19.3.6, pas dans les backports. Si votre entreprise connecte GitLab à un annuaire, c'est une raison de plus de rejoindre une branche récente.

Le CERT-FR a repris l'ensemble dans son avis CERTFR-2026-AVI-1363 du 22 octobre, et le CERT-EU dans son avis 2026-019.

Ce qu'on ne sait pas encore

Les sources lues ici ne parlent pas d'exploitation constatée, et le détail technique des failles ne sera public dans le suivi de GitLab que 90 jours après le correctif. Les « conditions » exactes de l'exploitation ne sont pas décrites dans le bulletin. Si votre GitLab n'est accessible que par VPN, le risque venant d'Internet est plus faible, mais c'est une déduction : la mise à jour reste nécessaire.

Le même réflexe vaut pour les autres briques d'un site : nous l'avons décrit pour la faille PHP2Shell et pour la porte dérobée via UpdraftPlus.

Ce qu'il faut retenir

• CVE-2026-110264 permet, dans certaines conditions, d'exécuter du code sur un GitLab auto-hébergé sans compte. GitLab.com est déjà corrigé.
• Toutes les versions CE/EE depuis la 7.0 sont concernées : visez 19.5.1, 19.4.3 ou 19.3.6.
• Les backports 19.2.9, 19.1.9, 19.0.10 et 18.11.13 ne corrigent que la faille critique.
• Après la mise à jour, cherchez les plantages [BUG] liés à org-ruby ou Onigmo, en gardant en tête qu'une attaque réussie peut ne laisser aucun plantage.

Si vous préférez qu'on suive ces mises à jour à votre place, c'est le rôle de notre offre de maintenance.