GitLab 19.5.1 corrige une faille d'exécution de code notée 10.0

GitLab a publié le 21 octobre 2026 des correctifs pour CVE-2026-110264, une faille notée 10.0, le maximum de l'échelle de gravité CVSS. Un bug dans le compilateur d'expressions régulières de GitLab pouvait permettre à un attaquant sans compte d'exécuter du code sur un serveur GitLab. GitLab.com est déjà corrigé, mais chaque installation autogérée doit être mise à jour.

En quoi consiste la faille

Une expression régulière, ou regex, est un motif qui sert à chercher et à reconnaître du texte. GitLab compile ces motifs en instructions avant de les exécuter. Ici, le compilateur subit un dépassement d'entier : un nombre grandit au-delà de ce que sa zone de stockage peut contenir et repart à zéro, ce qui peut corrompre la mémoire.

D'après la publication de correctif de GitLab, une regex spécialement conçue déclenche ce dépassement. Cela « aurait pu permettre à un utilisateur non authentifié d'exécuter du code arbitraire sur le serveur GitLab ». La faille touche à la fois la Community Edition et l'Enterprise Edition, jusqu'à GitLab 7.0.

L'attaque passe par le réseau et ne demande ni privilège ni action d'un utilisateur, rapporte GBHackers. Une personne connue sous le nom de joaxcar l'a signalée via le programme de bug bounty de GitLab sur HackerOne. Aucune source ne fait état d'attaques réelles ni d'un exploit public. GIGAZINE note que le bug ne figure pas sur la liste des vulnérabilités exploitées connues de la CISA.

Les versions qui corrigent la faille

GitLab a corrigé sept branches de publication d'un coup :

Branche	Version corrigée
19.5	19.5.1
19.4	19.4.3
19.3	19.3.6
19.2	19.2.9
19.1	19.1.9
19.0	19.0.10
18.11	18.11.13

Les quatre branches les plus anciennes ont reçu le correctif de CVE-2026-110264 par rétroportage. Les clients GitLab Dedicated en 19.3.5-internal0, 19.4.2-internal0 ou plus récent disposent déjà des correctifs.

Les 11 autres correctifs

La version corrige 12 vulnérabilités au total : une critique, deux élevées, cinq moyennes et quatre faibles. Les 12 sont corrigées dans 19.3.6, 19.4.3 et 19.5.1.

Les deux failles élevées concernent les équipes qui utilisent l'authentification unique. CVE-2026-15723, notée 8,2, est un défaut d'authentification dans la liaison automatique d'OmniAuth vers LDAP, mais seulement quand SAML et la liaison automatique LDAP sont tous deux activés. CVE-2026-112212, notée 7,5, permet l'empoisonnement du cache sur les points de découverte OAuth et OpenID Connect.

Un mois chargé pour la sécurité de GitLab

Ce n'est pas le premier correctif critique de GitLab en octobre. Dix jours plus tôt, GitLab avait averti de CVE-2026-97229, une autre faille notée 10.0 dans le compilateur de regex de CI/CD, rapporte BleepingComputer. Selon GIGAZINE, ce correctif du 12 octobre traitait 24 problèmes, et les serveurs qui n'ont que celui-ci restent exposés au nouveau bug.

BleepingComputer cite aussi Shadowserver, qui suit plus de 2 700 instances GitLab CE accessibles depuis Internet. Ce chiffre mesure l'exposition, pas des attaques confirmées.

Le conseil de GitLab est sans détour : « nous recommandons vivement de mettre à jour immédiatement toutes les installations GitLab autogérées vers l'une de ces versions ».

Ce que cela signifie pour les développeurs

Un serveur GitLab auto-hébergé contient le code source et les secrets de CI d'une entreprise, donc un bug d'exécution de code sans connexion est aussi grave que possible.

• Mettez à jour aujourd'hui et prévoyez l'interruption. 19.3.6 et 19.4.3 contiennent des migrations de base de données. Les installations à un seul nœud doivent être arrêtées pendant leur exécution, tandis que les configurations multinœuds peuvent utiliser la procédure sans interruption de GitLab.
• Quittez les branches les plus anciennes. GitLab ne liste l'ensemble des 12 correctifs que pour 19.3.6 et les versions suivantes. Les anciennes branches, de 18.11.13 à 19.2.9, sont citées pour le correctif critique.
• Cherchez des signes d'attaque. GitLab a publié deux détections pour les instances autogérées, onigmo_native_worker_crash et org_mode_render_error_burst. Cherchez-les dans vos journaux.
• Réduisez l'exposition. Si votre GitLab n'a pas besoin d'être sur l'Internet public, placez-le derrière un VPN ou une passerelle d'authentification unique.
• Changez les secrets en cas de doute. Un serveur GitLab compromis expose les variables de CI/CD et les clés de déploiement. Si vous trouvez des signes d'intrusion, renouvelez-les toutes.