FiveM
Minecraft
Rust
RedM
HytaleLe 12 octobre 2026, GitLab a publié les versions correctives 19.2.8, 19.3.5 et 19.4.2 de GitLab Community Edition (CE) et Enterprise Edition (EE) pour corriger 25 vulnérabilités de sécurité, dont CVE-2026-97229, un integer overflow critique dans le compilateur d'expressions régulières du moteur CI/CD. Cette faille de sécurité informatique est notée CVSS 10.0 (score maximal) : un attaquant non authentifié peut exécuter du code arbitraire à distance sur le serveur GitLab en injectant une expression régulière malveillante dans un fichier de configuration de pipeline .gitlab-ci.yml. Le 29 octobre 2026, la CISA a ajouté CVE-2026-97229 à son catalogue KEV (Known Exploited Vulnerabilities), confirmant une exploitation active en cours. Si vous hébergez une instance GitLab auto-gérée sur un VPS Linux ou un serveur dédié, la mise à jour vers une version corrigée est la seule remédiation disponible : il n'existe aucun contournement.
Sources : GitLab patch release 19.4.2, CISA KEV Catalog, Rapid7 (analyse technique).
Comprendre la faille CVE-2026-97229
CVE-2026-97229 est classée CWE-190 (Integer Overflow or Wraparound). Le défaut se situe dans le compilateur d'expressions régulières Onigmo, le moteur regex natif intégré à Ruby, utilisé par GitLab pour traiter les scripts de pipelines CI/CD contenus dans les fichiers de configuration .gitlab-ci.yml. Lorsqu'un fichier de pipeline contient une expression régulière dans une directive rules:exists ou rules:changes, GitLab compile cette regex pour l'évaluer contre les chemins de fichiers du dépôt. C'est à cette étape de compilation que se produit le dépassement d'entier : le calcul de la taille du programme regex compilé dépasse la valeur maximale d'un entier signé 32 bits, produisant un résultat négatif qui passe la vérification interne de taille et provoque une corruption de la mémoire du processus serveur.
Le vecteur CVSS 3.1 est AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H : l'attaque passe par le réseau, sans aucune authentification préalable et sans interaction utilisateur, avec un impact total sur la confidentialité, l'intégrité et la disponibilité du serveur. Sur une instance GitLab auto-hébergée qui autorise la création de projets publics ou l'accès aux dépôts sans authentification, un attaquant peut déclencher la vulnérabilité via l'API de lint CI/CD (/api/v4/projects/{id}/ci/lint) en envoyant une simple requête GET non authentifiée qui force la compilation de la regex malveillante.
Le mécanisme d'exploitation repose sur un contournement du scanner de quantificateurs de GitLab. Le scanner ne reconnaît que les chiffres contigus dans les quantificateurs regex. En insérant un commentaire inline ((?#)) au milieu d'un nombre, l'attaquant masque la véritable valeur de répétition : GitLab voit un petit quantificateur, mais Onigmo interprète le nombre complet. Combinée à des classes de caractères POSIX ([[:word:]]) qui se dilatent lors de la recompilation UTF-8, cette technique produit un programme regex dont la taille dépasse INT_MAX d'environ 30 000 octets. Le code malveillant est alors intégré dans les données de bitmap des classes de caractères, permettant l'exécution de commandes système sous l'identité de l'utilisateur git du serveur GitLab.
Exploitation active confirmée par la CISA
Le 29 octobre 2026, la CISA (Cybersecurity and Infrastructure Security Agency) a ajouté CVE-2026-97229 à son catalogue KEV, signalant une exploitation active confirmée dans la nature. L'agence fédérale américaine impose aux agences gouvernementales une date limite de remédiation fixée au 1er novembre 2026, avec obligation de triage forensique (BOD 26-04). Pour tout administrateur d'instance GitLab auto-hébergée, ce signal d'alerte est sans équivoque : deux semaines et demie après la publication du correctif de sécurité, les instances non mises à jour sont désormais des cibles actives d'attaques.
Des tentatives d'exploitation ont déjà été documentées publiquement. Entre le 20 et le 26 octobre 2026, un attaquant a ciblé l'instance GitLab d'Alpine Linux en soumettant des configurations CI/CD malveillantes contenant des expressions régulières spécialement construites. L'attaque a provoqué huit crashs de workers GitLab (processus Puma), dont quatre ont montré une progression partielle avant d'échouer. L'équipe d'Alpine Linux a estimé que l'attaque "est passée près de fonctionner" et a reconstruit son instance depuis zéro le 27 octobre 2026, en réinitialisant tous les mots de passe et clés secrètes par mesure de précaution.
Un code d'exploitation fonctionnel (PoC) publié par Rapid7 le 16 octobre 2026 est disponible publiquement, ce qui abaisse considérablement la barrière d'entrée pour les attaquants. Ce PoC exécute une commande shell arbitraire en tant qu'utilisateur git sur le serveur cible via une simple requête HTTP non authentifiée. L'exploitation nécessite environ 2 Go de RAM sur le worker Puma et cible les serveurs Linux sur processeur amd64.
Versions de GitLab touchées et correctifs disponibles
La vulnérabilité CVE-2026-97229 touche toutes les versions de GitLab CE et EE des branches 19.2, 19.3 et 19.4 antérieures aux correctifs de sécurité. Les versions corrigées ont été publiées le 12 octobre 2026 dans le cadre d'une release corrective planifiée :
| Branche GitLab | Versions vulnérables | Version corrigée (patch) |
|---|---|---|
| 19.2.x | 19.2.0 à 19.2.7 | 19.2.8 |
| 19.3.x | 19.3.0 à 19.3.4 | 19.3.5 |
| 19.4.x | 19.4.0 à 19.4.1 | 19.4.2 |
La version 19.3.4, initialement publiée comme correctif, contenait un bug affectant les pages de merge requests lorsque l'intégration Ona était activée. GitLab l'a remplacée par la version 19.3.5. Si vous avez installé la 19.3.4, votre instance reste vulnérable à CVE-2026-97229 : passez à la 19.3.5.
Au total, cette release corrective de sécurité adresse 25 vulnérabilités, dont quatre autres classées comme élevées (High) : une faille XSS dans la coloration syntaxique (CVE-2026-92883, CVSS 8.7), un contournement d'autorisation dans les pipelines en aval (CVE-2026-16301, CVSS 8.5), un problème d'accès aux fichiers via regex (CVE-2026-14814, CVSS 8.2) et une faille d'autorisation dans les pipelines planifiés (CVE-2026-81839, CVSS 7.7, EE uniquement). La release inclut également la correction d'une vulnérabilité d'injection de prompt LLM dans Duo Agent (CVE-2026-96893, CVSS 7.3, EE).
Chronologie des événements
| Date | Événement |
|---|---|
| 12 octobre 2026 | GitLab publie les versions correctives 19.2.8, 19.3.5, 19.4.2 (correctif de sécurité) |
| 13 octobre 2026 | Publication de l'avis de sécurité officiel et des détails de la vulnérabilité |
| 16 octobre 2026 | Rapid7 publie un code d'exploitation fonctionnel (PoC) et une analyse technique détaillée |
| 20-26 octobre 2026 | Tentatives d'exploitation documentées contre l'instance GitLab d'Alpine Linux |
| 27 octobre 2026 | Alpine Linux reconstruit son instance GitLab depuis zéro par précaution |
| 29 octobre 2026 | La CISA ajoute CVE-2026-97229 au catalogue KEV (exploitation active confirmée) |
Vérifier la version de votre instance GitLab
Ouvrez un shell SSH sur votre serveur VPS Linux ou serveur dédié hébergeant votre instance GitLab et vérifiez la version installée en ligne de commande. Pour une installation Omnibus (le mode d'installation le plus courant pour les instances auto-hébergées) :
sudo gitlab-rake gitlab:env:infoPour afficher uniquement le numéro de version de GitLab sans les informations système :
cat /opt/gitlab/embedded/service/gitlab-rails/VERSIONSi le numéro de version est inférieur à 19.2.8, 19.3.5 ou 19.4.2 selon la branche installée sur votre serveur, votre instance GitLab est vulnérable à l'exécution de code à distance et doit être mise à jour sans délai.
Pour les installations Docker, vérifiez le tag de l'image GitLab en cours d'exécution :
docker inspect gitlab/gitlab-ce:latest | grep -i versionMettre à jour GitLab pour corriger la vulnérabilité
Avant toute mise à jour de GitLab, sauvegardez vos données et créez un snapshot de votre serveur si votre hébergeur le propose. La mise à jour corrige la vulnérabilité CVE-2026-97229 et les 24 autres failles de sécurité incluses dans cette release. Pour une installation Omnibus, la mise à jour s'effectue via le gestionnaire de paquets du système d'exploitation de votre serveur.
Debian / Ubuntu
sudo apt update && sudo apt install gitlab-cePour GitLab Enterprise Edition, remplacez gitlab-ce par gitlab-ee :
sudo apt update && sudo apt install gitlab-eeCentOS / RHEL / AlmaLinux
sudo yum install gitlab-ceAprès l'installation du paquet, GitLab se reconfigure automatiquement. La release inclut des migrations de base de données qui peuvent allonger la durée de mise à jour. Sur une instance mono-serveur, prévoyez une interruption de service temporaire. Après l'installation du package, vérifiez que tous les services fonctionnent avec sudo gitlab-ctl status. Si un composant ne redémarre pas correctement, relancez-le avec sudo gitlab-ctl restart. Vérifiez ensuite la version installée :
cat /opt/gitlab/embedded/service/gitlab-rails/VERSIONPour les installations Docker, mettez à jour le tag de l'image vers la version corrigée et recréez le conteneur. Pour la gestion de Docker sur votre serveur, consultez notre guide installer Docker sur un VPS.
Aucun contournement (workaround) ne corrige cette vulnérabilité. Désactiver l'accès anonyme aux projets publics, interdire la création de projets par des utilisateurs non authentifiés ou bloquer la route /api/v4/*/ci/lint au niveau du reverse proxy réduit la surface d'attaque, mais ne supprime pas le risque d'exécution de code à distance. La mise à jour vers une version corrigée de GitLab est la seule remédiation efficace. Le correctif technique remplace la multiplication vulnérable dans le calcul de taille par une division qui ne peut pas provoquer de dépassement d'entier.
GitLab.com et GitLab Dedicated : déjà patchés
Si vous utilisez GitLab.com (l'offre SaaS hébergée par GitLab) ou GitLab Dedicated (l'offre managée en instance isolée), aucune action n'est nécessaire de votre part. GitLab a appliqué les correctifs de sécurité sur son infrastructure et sur toutes les instances Dedicated avant la publication de l'avis de sécurité. Seules les instances auto-hébergées (self-managed) de GitLab CE et EE installées sur votre propre serveur nécessitent une intervention manuelle pour appliquer le patch.
Gestion des correctifs : configurer un processus de mise à jour sur votre serveur distant
La gestion des correctifs est une composante essentielle de la sécurité informatique des instances GitLab auto-hébergées. CVE-2026-97229 rappelle qu'un bug critique peut être exploité activement quelques jours après sa divulgation. Configurer un processus de veille et de mise à jour rigoureux sur votre serveur réduit le temps d'exposition aux vulnérabilités connues.
- Surveiller les annonces de sécurité : abonnez-vous au flux RSS des release notes GitLab. GitLab publie ses correctifs le deuxième et le quatrième mercredi de chaque mois. Un paramétrage proactif de la veille vous permet de réagir avant que les bugs soient exploités activement.
- Automatiser avec un script shell : créez un script qui vérifie la version GitLab installée, sauvegarde la base de données PostgreSQL avec
gitlab-backup create, installe le package correctif via le gestionnaire de paquets et vérifie que les services redémarrent correctement. Planifiez ce script via une tâche cron pour automatiser la gestion des correctifs ou au minimum recevoir une notification lorsqu'un nouveau package est disponible. - Tester avant la production : si vos ressources en RAM et en processeur le permettent, maintenez une instance GitLab de staging sur un second VPS. Appliquez-y le correctif en premier pour vérifier la compatibilité avec vos scripts CI/CD et vos intégrations avant de mettre à jour le serveur distant de production.
- Restreindre l'accès réseau : limitez l'accès à votre instance GitLab par adresse IP source via le pare-feu. Configurez les enregistrements DNS pour que seuls les noms de domaine autorisés pointent vers votre instance, et placez un reverse proxy Nginx devant GitLab pour filtrer les requêtes suspectes avant qu'elles n'atteignent le serveur web applicatif.
Détecter une tentative d'exploitation sur votre serveur
Après avoir appliqué le correctif, vérifiez si votre instance GitLab a fait l'objet de tentatives d'exploitation avant la mise à jour. GitLab a publié six signatures de détection de menaces (threat detections) pour aider les administrateurs d'instances auto-gérées à identifier les attaques liées à CVE-2026-97229. Voici les indicateurs de compromission à rechercher dans les journaux de votre serveur :
- Crashs de workers Puma : des redémarrages de workers GitLab (processus Puma) coïncidant avec des requêtes vers l'API CI/CD, avec
regexp_matcher.rbdans les traces de pile. Vérifiez les journaux dans/var/log/gitlab/puma/. - Requêtes suspectes vers l'API de lint : dans les journaux Workhorse (
/var/log/gitlab/gitlab-workhorse/), recherchez des requêtes GET de longue durée (plusieurs secondes) vers/api/v4/projects/*/ci/lintsuivies de réponses HTTP 502 ("badgateway: failed to receive response: EOF"). - Artefacts dans les dépôts : des commits contenant des quantificateurs regex avec commentaires inline (
(?#)), des classes de caractères POSIX[[:word:]]répétées, et des chemins de fichiers avec des caractères UTF-8 sur quatre octets.
Si vous détectez des indicateurs de compromission, considérez votre instance comme potentiellement compromise. Changez immédiatement tous les mots de passe, révoquez les tokens d'accès personnel et les clés de déploiement, et créez une sauvegarde des journaux avant toute réinitialisation. L'exemple d'Alpine Linux montre qu'une reconstruction complète de l'instance peut être nécessaire en cas de compromission confirmée.
Sécuriser le serveur qui héberge GitLab
Appliquer le correctif de sécurité GitLab neutralise la vulnérabilité CVE-2026-97229, mais la sécurité globale de votre instance dépend aussi de la configuration du serveur Linux sous-jacent. Profitez de cette mise à jour pour vérifier les fondamentaux de sécurité de votre infrastructure :
- Accès SSH : désactivez l'authentification par mot de passe et utilisez exclusivement des clés SSH pour l'administration du serveur. Notre guide sécuriser SSH sur VPS Linux détaille la procédure complète de durcissement.
- Mises à jour automatiques du système : configurez les mises à jour de sécurité automatiques du système d'exploitation pour ne pas dépendre d'une intervention manuelle à chaque nouvelle CVE publiée. Consultez notre guide automatiser les mises à jour de sécurité sur Ubuntu.
- Sauvegardes GitLab : vérifiez que vos sauvegardes GitLab (
gitlab-backup create), incluant la base PostgreSQL et les fichiers de config/etc/gitlab/, fonctionnent correctement. Testez la restauration et assurez-vous que la dernière sauvegarde est récente et intègre. - Pare-feu et accès réseau : limitez l'accès à votre instance GitLab aux adresses IP autorisées via le pare-feu de votre serveur. Configurez UFW ou nftables pour restreindre les ports exposés et bloquer les connexions non nécessaires. Vérifiez également la résolution DNS de votre serveur pour vous assurer qu'aucun enregistrement non autorisé ne pointe vers votre instance.
- Journaux d'activité et supervision : après l'application du patch, consultez les journaux GitLab dans
/var/log/gitlab/pour détecter d'éventuelles tentatives d'exploitation antérieures à la mise à jour. Mettez en place une supervision des journaux pour être alerté en cas de comportement anormal sur votre serveur.
Pour suivre les autres vulnérabilités critiques affectant les serveurs Linux et les logiciels auto-hébergés, consultez notre actualité sur la faille TCP du noyau Linux CVE-2026-98432.