GitLab : une faille exploitée demande de corriger le serveur et d’examiner l’exposition

Trois branches, trois correctifs

La description du CNA GitLab dans NVD vise les versions 19.2 antérieures à 19.2.8, 19.3 antérieures à 19.3.5 et 19.4 antérieures à 19.4.2. Les bornes CPE de la fiche concordent avec ces valeurs pour les éditions Community et Enterprise. Ne transformez pas 19.2.8 en seuil valable pour toutes les branches : une 19.4 plus élevée numériquement peut encore être touchée.

La configuration CI/CD décrit comment les tâches d’intégration et de déploiement s’exécutent. Ici, la validation insuffisante d’une expression régulière peut permettre d’exécuter du code sur le serveur. Les sources autorisées lues ne détaillent pas toutes les conditions : nous ne les remplaçons pas par une recette d’exploitation.

Les configurations NVD lues le 3 novembre nomment aussi Ruby : branche 3.3 avant 3.3.13, 3.4 avant 3.4.12 et 4.0 avant 4.0.8. La description de cette même fiche reste celle de la faille GitLab CI/CD. Ces entrées d’inventaire ne prouvent pas quelle version de Ruby est embarquée dans un paquet GitLab donné ni comment son correctif y est propagé. Ne remplacez pas la mise à jour GitLab et l’examen d’exposition par le seul résultat d’un scanner de runtime.

Faites défiler le tableau horizontalement pour lire toutes les colonnes.

La mise à jour ne répond pas à la question d’une intrusion

Le catalogue KEV signale une exploitation connue et demande un triage forensique pour cette CVE. Sa date du 1er novembre 2026 relève des obligations fédérales américaines auxquelles renvoie la CISA ; ce n’est pas une échéance légale universelle. Pour une instance exposée, la priorité pratique est de corriger et de faire examiner la période d’exposition, pas d’attendre ce délai.

Conservez les journaux disponibles et un moyen de restauration indépendant avant l’intervention. Demandez au responsable du service de confirmer la branche corrigée et le résultat de l’examen. Un scan de version ou la réussite d’une mise à jour ne prouve pas l’absence de compromission. Ces précautions sont des recommandations de SecuFocus ; nous n’avons inspecté aucune instance.

• Auto-hébergement : prévoir la maintenance et la restauration↗

Une autre faille change le repère de mise à jour

L’avis CERT-FR CERTFR-2026-AVI-1427, publié le 30 octobre, apporte un autre identifiant : CVE-2026-111943, un contournement de la politique de sécurité dans GitLab CE/EE et AI Gateway. Ses bornes de correctif, plus récentes, figurent ci-dessous. Cet avis ne confirme pas une exploitation active de cette seconde CVE : ne lui attribuez pas le statut KEV de CVE-2026-97229.

Le NVD décrit sous cet identifiant un correctif de validation de certificats dans Go crypto/x509, pas une seconde exécution de code dans CI/CD. Le tableau ci-dessous reprend les bornes produits du CERT-FR ; nous n’avons pas vérifié la propagation de ce correctif de dépendance dans les paquets GitLab.

Pour chaque composant installé, comparez sa propre branche et son numéro complet. Mettre CE/EE à jour ne prouve pas qu’une AI Gateway administrée séparément est corrigée. Ces nouveaux repères ne remplacent pas l’examen de la faille exploitée précédente. Nous n’avons pas installé ces versions ; le bulletin éditeur GitLab est hors de la liste autorisée de cette veille.

Faites défiler le tableau horizontalement pour lire toutes les colonnes.