CVE-2026-97229 est une vulnérabilité critique de GitLab qui peut permettre l’exécution de code à distance sans authentification par l’intermédiaire d’une expression régulière spécialement conçue dans la configuration CI/CD. Les administrateurs d’instances autogérées exécutant les versions concernées de GitLab 19.2, 19.3 ou 19.4 doivent installer respectivement les versions 19.2.8, 19.3.5 ou 19.4.2. GitLab.com avait déjà été corrigé lorsque GitLab a divulgué la faille le 12 octobre 2026.
Qu’est-ce que CVE-2026-97229?
CVE-2026-97229 est une vulnérabilité de dépassement d’entier ou de bouclage, classée CWE-190, dans le traitement des expressions régulières de GitLab CI/CD. GitLab a signalé le 12 octobre 2026 qu’une expression régulière spécialement conçue pouvait, dans certaines conditions, permettre à un attaquant non authentifié d’exécuter du code arbitraire sur le serveur GitLab.
Selon la fiche CVE publiée le 13 octobre 2026, cette vulnérabilité obtient un score CVSS v3.1 de 10.0, soit Critique. Son vecteur décrit une attaque accessible par le réseau, de faible complexité, ne nécessitant aucun privilège ni interaction utilisateur, avec un changement de périmètre et un impact élevé sur la confidentialité, l’intégrité et la disponibilité.
L’exécution de code à distance est une catégorie de vulnérabilité qui permet à un attaquant d’exécuter des commandes ou des logiciels sur un système cible depuis un autre appareil. Sur un serveur GitLab, le périmètre potentiel de l’impact dépasse l’application web: les dépôts, les variables CI/CD, les identifiants des runners, les jetons de déploiement, les registres de packages et les environnements de production connectés peuvent tous nécessiter un examen après une compromission présumée.
La note de 10.0 décrit la gravité technique, et non la preuve que des attaques ont eu lieu. Cette distinction est importante. Un score maximal justifie l’application urgente du correctif, mais ne justifie pas d’affirmer qu’une compromission a eu lieu sans éléments probants.
Quelles versions de GitLab sont affectées par CVE-2026-97229?
CVE-2026-97229 affecte GitLab Community Edition et Enterprise Edition 19.2.x avant 19.2.8, 19.3.x avant 19.3.5 et 19.4.x avant 19.4.2, selon l’avis de sécurité de GitLab du 12 octobre 2026. Les branches antérieures n’ont pas été répertoriées comme affectées par cette vulnérabilité spécifique.
| Branche de publication | Versions affectées | Première version corrigée | Réponse requise |
|---|---|---|---|
| GitLab 19.2 | 19.2.x avant 19.2.8 | 19.2.8 | Effectuez immédiatement la mise à niveau |
| GitLab 19.3 | 19.3.x avant 19.3.5 | 19.3.5 | Effectuez immédiatement la mise à niveau |
| GitLab 19.4 | 19.4.x avant 19.4.2 | 19.4.2 | Effectuez immédiatement la mise à niveau |
| Branches antérieures | Non répertoriées comme affectées par cette CVE | Sans objet | Suivre la politique habituelle relative aux versions prises en charge |
Ne vous arrêtez pas à la version 19.3.4. GitLab a indiqué le 13 octobre 2026 que la version 19.3.4 contenait un bug d’intégration avec Ona affectant les pages des demandes de fusion; la version corrigée désignée pour cette branche est donc la 19.3.5. Un miroir de packages ou une règle d’automatisation figée une version corrective en arrière vous laisserait sur la mauvaise version.
GitLab indique également qu’un avis s’applique à tous les types de déploiement lorsqu’il ne désigne pas un type d’installation particulier, tel qu’un package Linux, une installation depuis les sources ou un déploiement Helm. Les administrateurs doivent donc éviter de supposer que les conteneurs ou les installations Kubernetes sont exclus de l’avis.
GitLab.com avait déjà reçu le correctif lorsque l’avis a été publié le 12 octobre 2026. Il a été indiqué aux clients de GitLab Dedicated qu’aucune action n’était requise. Les mesures correctives urgentes concernent les organisations qui exploitent des instances autogérées.
Comment vérifier la version de GitLab installée?
Selon la documentation de GitLab consultée le 13 octobre 2026, les administrateurs GitLab peuvent identifier la version d’une instance authentifiée en ouvrant Aide, puis Aide, dans l’interface GitLab. Les installations utilisant un package Linux enregistrent également les versions des composants installés dans /opt/gitlab/version-manifest.txt, ce qui peut faciliter les vérifications d’inventaire lorsque l’interface est indisponible.
Inventoriez chaque instance, et pas seulement le nom d’hôte de production connu de l’équipe de sécurité. Les systèmes de développement, les nœuds de reprise après sinistre, les environnements de préproduction, les serveurs de test exposés à Internet et les déploiements régionaux oubliés peuvent contenir le même code CI/CD vulnérable tout en faisant l’objet d’une surveillance moindre.
Consignez pour chaque serveur l’édition, la version complète, la méthode de déploiement, l’exposition publique, le propriétaire et l’état de la mise à niveau. Comparez le numéro de correctif complet avec les versions corrigées de GitLab; voir uniquement «19.4» ne suffit pas à établir que le système est sûr.
Les équipes qui ont précédemment répondu à GitLab CVE-2026-85706 doivent tout de même effectuer un nouvel inventaire. Les éléments attestant de la correction d’une faille GitLab ne prouvent pas que les versions correctives ultérieures ont été installées dans tous les environnements.
Comment les administrateurs doivent-ils corriger CVE-2026-97229?
Les administrateurs doivent mettre à niveau chaque instance GitLab autogérée affectée vers la version corrective correspondant à sa branche existante: 19.2.8, 19.3.5 ou 19.4.2. L’avis de mise à jour de GitLab du 12 octobre 2026 indique que les correctifs contiennent des migrations de base de données; la planification de la maintenance doit donc tenir compte de la topologie du déploiement et des opérations de migration.
Utilisez la procédure de mise à niveau prise en charge par GitLab pour votre méthode d’installation et conservez une sauvegarde récupérable avant de modifier le système. Lisez les notes de version, confirmez que l’espace de stockage disponible est suffisant, vérifiez l’état de la base de données et testez le même parcours de mise à niveau dans un environnement représentatif hors production lorsque les contraintes opérationnelles le permettent.
La séquence de réponse suivante permet de maintenir un ordre pratique entre l’application du correctif, la validation et la préservation des éléments de preuve:
- Inventoriez chaque serveur GitLab autogéré et identifiez sa version complète installée.
- Limitez les accès publics évitables pendant la préparation de la mise à niveau, sans considérer la réduction de l’exposition comme un correctif.
- Sauvegardez la configuration, les dépôts, les secrets et les bases de données en utilisant le processus de récupération testé par l’organisation.
- Installez GitLab 19.2.8, 19.3.5 ou 19.4.2 pour la branche affectée correspondante.
- Effectuez les migrations de base de données et les migrations post-déploiement requises, puis vérifiez leur état.
- Confirmez la version affichée, testez l’accès aux dépôts et exécutez un pipeline CI/CD contrôlé.
- Examinez l’activité récente des pipelines et du serveur, en préservant les journaux suspects avant que la conservation habituelle ne les supprime.
GitLab a indiqué en 2026 que les mises à niveau d’un nœud unique impliquant ces migrations entraînent une interruption de service, tandis que les mises à niveau correctement effectuées sur plusieurs nœuds peuvent éviter cette interruption. La version 19.3.5 comprend également des migrations post-déploiement. En termes simples, télécharger le package ne constitue qu’une partie du travail; vous devez ensuite vérifier l’état de l’application et des migrations.
Le calcul du temps nécessaire est simple. Si une organisation possède 24 instances et a besoin de 15 minutes pour inventorier et valider chacune d’elles, un traitement séquentiel consomme 360 minutes, soit 6 heures, avant même le dépannage. Une répartition parallèle entre quatre administrateurs réduit cette fenêtre nominale de validation à 90 minutes, en supposant des charges de travail équivalentes et l’absence d’échec lors des mises à niveau.
Honnêtement, reporter le correctif d’un serveur présentant une gravité maximale afin de préserver une fenêtre de maintenance ordinaire n’a guère de sens lorsqu’une exécution de code sans authentification est possible. Pour appliquer une discipline de triage plus large, la même approche de priorisation des actifs utilisée pour les déploiements de correctifs à volume élevé peut aider à distinguer les serveurs GitLab exposés publiquement des systèmes internes présentant un risque moindre.
CVE-2026-97229 a-t-elle été exploitée dans la nature?
Aucune source faisant autorité examinée n’avait confirmé l’exploitation active de CVE-2026-97229 au 13 octobre 2026. Tenable a classé la vulnérabilité comme « faisant l’objet d’une surveillance » tout en recherchant des preuves de concept ou des informations sur son exploitation ; ce statut de surveillance ne prouve pas que des attaquants ont exploité la faille dans des environnements réels.
L’avis de sécurité de GitLab établit l’existence de la vulnérabilité, les versions concernées, la possibilité d’exécution de code sans authentification et les correctifs disponibles. Il n’établit pas qu’un serveur particulier a été attaqué. Les administrateurs doivent maintenir ces affirmations distinctes dans les rapports d’incident, les mises à jour destinées à la direction et les communications aux clients.
Aucun indicateur de compromission fourni par le fournisseur ni aucune signature de recherche spécifiquement liée à la CVE n’a été trouvé dans les sources examinées le 13 octobre 2026. En attendant de disposer de renseignements plus précis, examinez les modifications inattendues de la configuration CI/CD, les exécutions anormales de pipelines, les plantages de workers, les processus serveur inconnus, les mécanismes de persistance nouvellement créés et les connexions sortantes inhabituelles.
Examinez les journaux d’accès et les événements d’audit liés à la création ou à la modification suspecte de pipelines, mais ne vous attendez pas à ce qu’une seule ligne de journal permette de trancher la question. Si une compromission de l’hôte est plausible, préservez les preuves volatiles, isolez le serveur conformément à votre plan de réponse aux incidents, faites tourner les identifiants exposés et examinez les runners connectés ainsi que les cibles de déploiement. La logique de réponse ressemble à la recherche de persistance décrite dans le guide de correctifs et de recherche de JFrog Artifactory.
Une analyse de vulnérabilités propre après la mise à niveau prouve que la version détectée a changé ; elle ne prouve pas que le serveur n’a jamais été compromis avant l’application du correctif. C’est précisément ce cas limite souvent négligé qui explique pourquoi la remédiation et la recherche de menaces doivent être menées comme des activités liées, mais distinctes.
Comment réduire l’exposition de GitLab après l’application du correctif ?
GitLab recommande de désactiver la création de comptes inutile et de restreindre la visibilité publique afin de réduire l’exposition évitable, conformément à ses directives d’administration disponibles en 2026. Ces mesures de renforcement peuvent limiter les voies d’accès, mais aucune ne corrige CVE-2026-97229 ni ne remplace l’installation de GitLab 19.2.8, 19.3.5 ou 19.4.2.
Limitez l’accès réseau aux interfaces d’administration lorsque les exigences métier le permettent, vérifiez qui peut modifier la configuration CI/CD et protégez les variables à forte valeur au moyen d’une portée et de contrôles d’environnement appropriés. Vous devez également examiner l’enregistrement des runners, les jetons obsolètes, la connectivité sortante et les intégrations susceptibles de transformer la compromission d’un hôte GitLab en accès à d’autres ressources.
La visibilité publique des projets et l’inscription ouverte peuvent constituer des choix légitimes pour le produit. Ne les désactivez pas aveuglément. Documentez la raison métier, mettez en place une surveillance compensatoire et assurez-vous que le responsable de la décision comprend qu’une plateforme de développement accessible publiquement attire davantage d’analyses automatisées et d’abus.
La confiance accordée à la CI/CD dépend également de ce que les outils automatisés introduisent dans les dépôts et les fichiers de build. Les équipes qui adoptent des systèmes de génération de code doivent tenir compte des risques liés aux dépendances créés par le codage assisté par l’IA dans le cadre de leur examen postérieur à l’application du correctif.
Questions fréquemment posées
CVE-2026-97229 affecte-t-elle GitLab.com ?
GitLab.com avait déjà été corrigé lorsque GitLab a publié son avis de sécurité le 12 octobre 2026. Il a été indiqué aux clients de GitLab Dedicated qu’aucune action n’était requise.
GitLab 19.3.4 est-elle protégée contre cette vulnérabilité ?
GitLab 19.3.4 n’est pas la version désignée comme corrigée pour CVE-2026-97229. GitLab demande aux administrateurs de la branche 19.3 d’installer la version 19.3.5, qui évite également un bug d’intégration avec Ona affectant les pages des demandes de fusion dans la version 19.3.4.
Un pare-feu peut-il remplacer la mise à jour de sécurité de GitLab ?
Un pare-feu peut réduire l’exposition, mais il ne peut pas corriger le traitement vulnérable des expressions régulières CI/CD dans GitLab. Les installations autogérées concernées nécessitent toujours la version corrigée appropriée d’octobre 2026.
Un score CVSS de 10,0 prouve-t-il une exploitation ?
Un score CVSS v3.1 de 10,0 décrit la gravité technique de la vulnérabilité et son impact potentiel. Le score de 2026 ne prouve pas que CVE-2026-97229 a été exploitée contre des systèmes réels.