Les administrateurs GitLab qui ont corrigé leurs serveurs le 12 octobre doivent les mettre à jour à nouveau. Une deuxième vulnérabilité de gravité maximale touche les installations exécutant ces correctifs précédents.
Le 21 octobre 2026, GitLab a publié des correctifs pour la CVE-2026-110264, une faille d'exécution de code à distance (RCE) touchant les installations Community Edition (CE) et Enterprise Edition (EE) autogérées. Notée 10,0 selon CVSS 3.1, cette vulnérabilité pourrait permettre à des attaquants non authentifiés d'exécuter du code arbitraire dans certaines conditions.
Contrairement à la CVE-2026-97229, corrigée neuf jours plus tôt, la nouvelle vulnérabilité RCE de GitLab touche des versions remontant à 2014. Même les organisations qui ont installé les correctifs du 12 octobre doivent effectuer une nouvelle mise à jour.
Une nouvelle faille RCE de GitLab touche des versions remontant à 2014
Selon l'avis de sécurité de GitLab du 21 octobre, la CVE-2026-110264 est due à un dépassement d'entier lors de la compilation d'une expression régulière spécialement conçue. Une exploitation réussie pourrait compromettre un serveur affecté sans nécessiter d'identifiants valides.
L'analyse de Censys du 22 octobre identifie le rendu des fichiers (.org) Org-mode dans les projets publics comme une voie d'attaque potentielle. Une exploitation pourrait exécuter du code sous legit compte de GitLab, ce qui pourrait exposer les dépôts et les identifiants CI/CD.
La précédente faille CVE-2026-97229 concernait la validation des expressions régulières dans les configurations CI/CD. Les deux vulnérabilités affichent un score CVSS de 10,0, mais nécessitent des correctifs distincts. Les versions 19.4.2, 19.3.5 et 19.2.8 restent affectées par la faille la plus récente.
Parmi les autres problèmes de sécurité récents de GitLab figurent une vulnérabilité GraphQL d'août, une faille de septembre ajoutée au catalogue des vulnérabilités exploitées de la CISA, ainsi qu'une faille d'exécution de commandes d'AI Gateway en octobre. Ces incidents concernaient des failles de sécurité distinctes.
Le 21 octobre, Censys a identifié 81 820 hôtes GitLab visibles depuis Internet. Plus de la moitié d'entre eux étaient estimés exécuter des branches de versions vieilles de plus de sept mois, même si ces résultats ne permettent pas d'établir combien d'installations étaient vulnérables ou compromises. Au 22 octobre, Censys n'avait identifié aucune exploitation confirmée dans la nature ni aucun code public de preuve de concept vérifié pour la CVE-2026-110264.
Versions GitLab concernées et recommandations de mise à jour
GitLab a publié sept versions corrigées, dont quatre rétroportages supplémentaires pour les anciennes versions CE et EE.
| Versions concernées | Version corrigée |
|---|---|
| 19.5.0 | 19.5.1 |
| 19.4 antérieure à 19.4.3 | 19.4.3 |
| 19.3 antérieure à 19.3.6 | 19.3.6 |
| 19.2 antérieure à 19.2.9 | 19.2.9 |
| 19.1 antérieure à 19.1.9 | 19.1.9 |
| 19.0 antérieure à 19.0.10 | 19.0.10 |
| De 7.0 à 18.11.12 | 18.11.13 ou toute version corrigée applicable ultérieure |
Les anciennes installations doivent suivre les instructions de mise à niveau de GitLab. Certaines mises à jour nécessitent des migrations de base de données et peuvent entraîner une interruption de service sur les systèmes à nœud unique. GitLab.com et les installations GitLab Dedicated correctement corrigées disposent déjà des correctifs.
GitLab a également publié deux détections : « Onigmo native worker crash » et « Org mode render error burst ». L'avis de CERT-EU du 22 octobre recommande de donner la priorité aux systèmes exposés sur Internet et d'évaluer les compromissions potentielles.
Les équipes de sécurité doivent :
- Identifier les installations concernées : Inventorier les versions de GitLab sur les systèmes de production, de développement et de test.
- Installer les mises à jour de sécurité : Appliquer les versions corrigées, vérifier les versions installées et contrôler les sauvegardes avant la mise à niveau.
- Réduire l'exposition inutile : Restreindre l'accès public lorsque cela est possible et limiter les connexions réseau sensibles.
- Rechercher les activités suspectes : Vérifier les erreurs de rendu, les processus inattendus, l'activité du
gitcompte et les modifications des clés SSH. - Évaluer une compromission potentielle : Examiner les identifiants, les dépôts et les pipelines. Faire tourner les secrets exposés si nécessaire.
- Tester les plans de réponse aux incidents : Valider l'isolement, la conservation des éléments de preuve, la rotation des identifiants et les procédures de récupération.
La surveillance et les restrictions d'accès peuvent réduire l'exposition, mais elles n'éliminent pas la vulnérabilité. Les administrateurs doivent installer une version corrigée applicable, même s'ils ont effectué une mise à jour plus tôt en octobre.
En savoir plus : la compromission du registre Coder impliquant des modules Terraform malveillants montre comment des attaques contre l'infrastructure de développement peuvent exposer des identifiants cloud et des secrets CI/CD.