GitLab : même les serveurs mis à jour le 12 octobre doivent encore être corrigés

GitLab a corrigé le 21 octobre 2026 la faille CVE-2026-110264, qui permet, « sous certaines conditions », à un utilisateur non authentifié d'exécuter du code arbitraire sur un serveur GitLab auto-hébergé. Elle obtient la note maximale de 10,0 sur l'échelle CVSS et concerne toutes les versions depuis la 7.0, sortie en 2014. Les correctifs sont les versions 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 et 18.11.13, détaillées dans l'avis officiel de GitLab.

Un défaut dans le compilateur d'expressions régulières

D'après l'avis, la cause est un dépassement d'entier (integer overflow) survenant lors de la compilation d'une expression régulière spécialement forgée. Selon The Hacker News, le composant fautif est Onigmo, le moteur d'expressions régulières de Ruby, que GitLab embarque dans ses propres paquets. Toute version livrée avec ce moteur est donc exposée, ce qui explique l'ancienneté du problème.

GitLab n'a pas précisé les conditions nécessaires à l'exploitation. Les administrateurs ne peuvent donc pas s'exclure par une simple configuration, et l'éditeur ne propose aucun contournement provisoire : seule la mise à jour protège avec certitude. Dans son avis, GitLab écrit : « nous recommandons fortement que toutes les installations GitLab auto-hébergées soient mises à jour immédiatement » (traduction) (GitLab Docs).

Seules ces installations sont concernées. GitLab.com tourne déjà sur la version corrigée, tout comme les tenants GitLab Dedicated en 19.3.5-internal0 et 19.4.2-internal0 ou ultérieures.

Une quatrième faille du même type en un mois

La faille a été signalée par le chercheur joaxcar via le programme de primes HackerOne. Toujours selon The Hacker News, c'est la quatrième faille d'exécution de code dans ce moteur qu'il rapporte en un mois. Le 23 septembre, GitLab en avait corrigé deux (CVE-2026-93577 et CVE-2026-89078), notées 9,9 mais exigeant un compte connecté. Le 12 octobre, la CVE-2026-97229, également notée 10,0 et sans authentification, avait été traitée dans les versions 19.2.8, 19.3.5 et 19.4.2.

La nouveauté tient à la portée : les trois premières s'arrêtaient à la version 19.2, celle-ci remonte beaucoup plus loin. Le correctif du 12 octobre ne couvrait que les versions 19.2 et suivantes. Une instance mise à jour à ce moment-là se retrouve donc de nouveau vulnérable, la version corrigée se situant un cran au-dessus.

GitLab ne corrige normalement que la version courante et les deux précédentes, soit 19.5, 19.4 et 19.3. Pour cette faille, l'éditeur a exceptionnellement rétroporté le correctif vers les versions 18.11.13, 19.0.10, 19.1.9 et 19.2.9, une mesure qu'il réserve aux problèmes graves.

Selon The Hacker News, aucune exploitation n'est signalée et la faille ne figurait pas, au 22 octobre, dans le catalogue des vulnérabilités exploitées de l'agence américaine CISA. GitLab a aussi publié deux règles de détection, « Onigmo native worker crash » et « Org mode render error burst », au format Sigma, pour repérer d'éventuelles tentatives d'exploitation dans les journaux applicatifs.

Dix autres failles corrigées

Cette livraison comprend 11 correctifs de sécurité, dont un seul critique. Parmi les autres :

• CVE-2026-15723 (8,2, élevée) : un utilisateur connecté pourrait prendre le contrôle d'un compte LDAP existant, uniquement si l'association automatique SAML et LDAP est activée.
• CVE-2026-112212 (7,5, élevée) : un empoisonnement de cache des points d'accès OAuth/OIDC pourrait rediriger certains flux de connexion vers un serveur contrôlé par l'attaquant, avec un cache partagé.
• Des failles de gravité moyenne ou faible touchent notamment l'API GraphQL, l'API des jalons de groupe, les politiques d'approbation des merge requests et des fonctions d'IA payantes.

Prévoir une interruption

Les versions 19.4.3 et 19.3.6 contiennent des migrations de base de données exécutées pendant la mise à jour. Sur un serveur à nœud unique, elles entraînent une interruption de service, le temps qu'elles se terminent. Les déploiements multi-nœuds peuvent appliquer le correctif sans coupure en suivant la procédure de mise à jour sans interruption de GitLab.

Conformément à sa politique, GitLab rendra publics les tickets détaillant chaque vulnérabilité 90 jours après la version qui les corrige.