CVE-2026-110264 : Flaw RCE Critique dans GitLab Affectant 12 Ans de Versions

GitLab a publié des mises à jour de sécurité urgentes pour corriger la CVE-2026-110264, une vulnérabilité de gravité maximale qui pourrait permettre à un attaquant non authentifié d’exécuter du code arbitraire sur des serveurs GitLab autogérés vulnérables. La faille a un score CVSS de 10,0 et affecte à la fois GitLab Community Edition (CE) et Enterprise Edition (EE).

La vulnérabilité est particulièrement notable car le code affecté remonte à GitLab 7.0, publié en 2014. Cela laisse environ 12 ans de versions de GitLab dans la plage vulnérable, bien qu’il n’y ait actuellement aucune preuve que les attaquants aient exploité cette faiblesse au cours de cette période. GitLab a divulgué le problème et publié des versions corrigées le 21 octobre 2026.

La vulnérabilité provient d’un dépassement d’entier déclenché pendant que GitLab compile une expression régulière spécialement conçue. Dans certaines conditions, un attaquant non authentifié pourrait utiliser cette condition pour exécuter du code arbitraire sur le serveur GitLab sous-jacent. GitLab a intentionnellement retenu le chemin d’exploitation complet et les prérequis spécifiques pendant que les administrateurs déploient les correctifs.

Pour les organisations utilisant une infrastructure GitLab autogérée, l’impact potentiel est grave. Les dépôts GitLab contiennent souvent du code source, la configuration CI/CD, des secrets de déploiement, des jetons d’accès, des définitions d’infrastructure et des connexions aux environnements de production. Un compromis au niveau serveur pourrait donc créer des opportunités de vol d’identifiants, manipulation de dépôt, attaques de la chaîne d’approvisionnement, persistance ou déplacement latéral.

Les équipes de sécurité recherchant des opportunités de détection de la CVE-2026-110264 peuvent utiliser la plateforme SOC Prime’s AI-Native Detection Intelligence pour renforcer la visibilité sur l’exploitation des vulnérabilités et le comportement post-compromis associé dans les environnements SIEM, EDR et Data Lake.

Cliquez sur Explorer les Détections pour accéder au contenu de détection pertinent et à la logique de chasse. Pour détecter les tentatives d’exploitation de la CVE-2026-110264, les défenseurs devraient corréler la télémétrie de l’application GitLab avec l’exécution de processus, le comportement anormal du serveur et la logique de détection des menaces récemment publiée par GitLab.

Les praticiens de la sécurité peuvent également utiliser Prime Architect pour transformer les renseignements émergents sur les vulnérabilités en règles Sigma et requêtes de chasse, valider la logique de détection, générer des Attack Flows pertinents et traduire le contenu de détection sur les plateformes de sécurité prises en charge.

Contactez le service commercial

Analyse de la CVE-2026-110264

GitLab décrit la vulnérabilité comme un dépassement d’entier dans son compilateur d’expressions régulières. Dans certaines conditions, compiler une expression régulière spécialement conçue peut mener à l’exécution de code arbitraire sur le serveur GitLab sans authentification.

GitLab a attribué à la vulnérabilité le score maximal CVSS v3.1 de 10,0, avec le vecteur CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Cela reflète une vulnérabilité accessible par le réseau avec une complexité d’attaque faible, aucun privilège requis et aucune interaction utilisateur, avec un impact potentiellement élevé sur la confidentialité, l’intégrité et la disponibilité.

Le chercheur en sécurité joaxcar a découvert et signalé la vulnérabilité via le programme de primes aux bogues HackerOne de GitLab. Les notes de version de GitLab font également référence à des correctifs pour la gestion des expressions régulières Ruby, tandis que les rapports indiquent que le moteur sous-jacent affecté est Onigmo, l’implémentation d’expressions régulières de Ruby intégrée dans les packages GitLab.

CVE-2026-110264 affecte GitLab CE et EE sur une plage exceptionnellement large :

• GitLab 7.0 jusqu’aux versions antérieures à 18.11.13
• GitLab 19.0 avant 19.0.10
• GitLab 19.1 avant 19.1.9
• GitLab 19.2 avant 19.2.9
• GitLab 19.3 avant 19.3.6
• GitLab 19.4 avant 19.4.3
• GitLab 19.5 avant 19.5.1

GitLab a rétroporté le correctif vers 18.11.13, 19.0.10, 19.1.9 et 19.2.9 en plus de ses branches de correctifs prises en charge normales en raison de la gravité et de l’exposition exceptionnellement large.

La longue fenêtre de vulnérabilité ne signifie pas que la faille a été activement exploitée depuis 2014. Au contraire, la fonctionnalité d’expressions régulières vulnérable existait à travers les versions datant de GitLab 7.0. Ni GitLab ni les deux rapports fournis n’ont confirmé l’exploitation dans des attaques réelles au 22 octobre 2026.

Cette vulnérabilité ne doit pas non plus être confondue avec la CVE-2026-97229, une autre faille critique d’exécution de code à distance GitLab liée au traitement des expressions régulières qui a été corrigée plus tôt en octobre. Ce problème a affecté une plage plus restreinte de versions plus récentes. L’installation des correctifs du 12 octobre pour cette vulnérabilité ne protège pas automatiquement les systèmes contre cette nouvelle faille divulguée.

Les administrateurs qui ont récemment mis à jour GitLab doivent donc vérifier leur build installé exact plutôt que de supposer qu’une précédente mise à jour de sécurité d’octobre assure une protection suffisante.

Les détails actuellement disponibles pour la CVE-2026-110264 ne divulguent pas l’entrée, l’endpoint, la fonctionnalité ou les conditions exacts contrôlés par l’attaquant nécessaires pour atteindre le compilateur d’expressions régulières vulnérable. GitLab rend généralement les questions de sécurité détaillées publiques 90 jours après la publication contenant un correctif, réduisant la disponibilité immédiate des informations techniques exploitables pendant que les clients appliquent des correctifs.

Aucune preuve de concept CVE-2026-110264 publique n’a été divulguée dans les rapports fournis ou l’avis GitLab. Cybersecurity News note spécifiquement que GitLab n’a pas publié d’exploit public, tandis que l’entreprise a limité la divulgation du chemin d’attaque complet.

En même temps, l’absence de preuve de concept publique ne doit pas être interprétée comme un risque faible. Une vulnérabilité à distance, non authentifiée avec un score CVSS de 10,0 présente une cible attrayante, notamment parce que les serveurs GitLab autogérés sont souvent exposés à l’internet.

Il n’y a actuellement pas d’IOC spécifiques à la campagne CVE-2026-110264 tels que des adresses IP malveillantes, des domaines, des hachages de charges ou des modèles de requêtes d’exploitation confirmés parce que ni GitLab ni les chercheurs en sécurité cités n’ont signalé d’exploitation active.

GitLab a toutefois publié deux détections de menaces destinées à identifier les tentatives d’exploitation possibles sur les installations autogérées :

• Crash du travailleur natif Onigmo
• Éruption d’erreur de rendu en mode Org

Ces détections sont conçues pour identifier un comportement suspect lié aux tentatives de déclencher la vulnérabilité. Leur présence ne confirme pas par elle-même un compromis réussi et doit être corrélée avec une télémétrie plus large de l’application et de l’endpoint.

Les équipes de sécurité devraient enquêter sur les crashs inattendus de l’application GitLab, les rafales d’erreurs de rendu, les processus anormaux provenant de GitLab ou des composants Ruby, l’exécution de shells inattendue, les mécanismes de persistance nouvellement créés et les connexions sortantes depuis les serveurs GitLab qui dévient des schémas opérationnels normaux.

Mitigation de la CVE-2026-110264

GitLab recommande fortement à toutes les organisations opérant des installations autogérées affectées de mettre à jour immédiatement. Les versions corrigées sont :

GitLab.com a déjà été mis à jour. Les locataires GitLab Dedicated exécutant les versions internes 19.3.5-internal0, 19.4.2-internal0 ou ultérieures contiennent déjà les correctifs nécessaires et n’ont pas besoin d’agir pour cette vulnérabilité.

Les clients autogérés ne devraient pas retarder la remédiation en attendant des détails d’exploitation supplémentaires. GitLab n’a pas publié de solution alternative offrant une protection équivalente, faisant de l’installation de la version corrigée le chemin de remédiation le plus fiable.

Avant de mettre à jour, les administrateurs devraient examiner la documentation de mise à jour de GitLab et tenir compte des migrations de base de données. GitLab avertit que les déploiements à nœud unique peuvent connaître une indisponibilité pendant que les migrations se terminent, alors que les environnements multi-nœuds correctement configurés peuvent suivre le processus de mise à niveau sans interruption du fournisseur. Les versions 19.3.6 et 19.4.3 contiennent des migrations régulières, et 19.4.3 inclut également une migration post-déploiement.

Après avoir appliqué le correctif, les équipes de sécurité devraient effectuer une analyse rétrospective au lieu de considérer la mise à jour elle-même comme une preuve qu’un serveur n’a jamais été ciblé. Examinez les journaux d’application GitLab pour les deux indicateurs d’exploitation publiés par GitLab et enquêtez sur toute activité suspecte précédant la mise à jour.

Les défenseurs devraient également examiner la télémétrie du système d’exploitation pour :

• Processus enfants inattendus provenant de GitLab, Ruby ou travailleurs associés
• Exécution de shell ou d’interprète de script sous des comptes de service GitLab
• Nouvelles clés SSH ou comptes administratifs
• Modifications inattendues des dépôts ou des pipelines CI/CD
• Emplois planifiés ou mécanismes de persistance nouvellement créés
• Changements aux runners, jetons de déploiement, jetons d’accès personnel et jetons d’accès aux projets
• Connexions sortantes inhabituelles depuis le serveur GitLab
• Accès non autorisé aux secrets stockés dans les variables CI/CD
• Modifications inattendues de paquets, de versions ou de dépôts

Si un compromis est suspecté, les organisations devraient isoler le serveur, préserver les journaux et les artefacts de forensic, tourner les identifiants et jetons potentiellement exposés, et valider l’intégrité des dépôts et des flux de travail CI/CD avant de remettre l’instance en production.

Étant donné que les installations GitLab agissent souvent comme une infrastructure de confiance dans les pipelines de développement logiciel, les intervenants devraient également déterminer si un attaquant pourrait avoir modifié le code source, les artefacts, les images de conteneur, les modèles d’infrastructure en tant que code ou les flux de déploiement. Un serveur GitLab compromis peut créer un risque pour la chaîne d’approvisionnement en aval même après la remédiation du serveur d’origine.

La plateforme AI-Native Detection Intelligence de SOC Prime peut aider les organisations à renforcer leur posture de détection contre l’exploitation des vulnérabilités émergentes en fournissant un contenu de détection basé sur le comportement continuellement mis à jour, mappé à MITRE ATT&CK®.

Clause de non-responsabilité : Le contenu de détection peut ne pas être disponible pour chaque CVE. Vérifiez la plateforme SOC Prime pour la couverture actuelle. Si des détections pertinentes ne sont pas encore disponibles, revenez plus tard car de nouveaux renseignements sur les menaces et des contenus de détection sont continuellement ajoutés.