GitLab 19.0.1, 18.11.4 et 18.10.7 corrigent 7 CVE (CERTFR-2026-AVI-0658)

Le CERT-FR a publié le 28 mai 2026 l'avis CERTFR-2026-AVI-0658, qui répercute le bulletin GitLab du 27 mai 2026 annonçant les versions 19.0.1, 18.11.4 et 18.10.7 de GitLab Community Edition (CE) et Enterprise Edition (EE). Sept CVE sont corrigées, dont une faille de résolution d'identité dans les workflows Duo AI (CVE-2026-4868, CVSS 8,2) et plusieurs contournements d'autorisation côté GraphQL et API. Aucune exploitation active n'est mentionnée par GitLab ni le CERT-FR à la publication.

Vulnérabilités corrigées

• CVE-2026-4868 — CVSS 8,2. Résolution d'identité incorrecte au déclenchement d'un workflow Duo AI : un utilisateur authentifié peut, dans certaines conditions, faire exécuter un workflow Duo AI sous l'identité d'un autre utilisateur. Affecte GitLab EE de la 18.8 à la 18.10.7, la 18.11 à la 18.11.4, et la 19.0 à la 19.0.1.
• CVE-2026-5296 — défaut d'autorisation dans GitLab EE. Affecte de la 18.7 à la 18.10.7, la 18.11 à la 18.11.4, et la 19.0 à la 19.0.1. Contournement de flux d'authentification fondamentaux.
• CVE-2026-1402 — CVSS 6,5. Déni de service authentifié sur GitLab CE/EE : allocation excessive de ressources via une entrée mal validée, de la 17.1 à la 18.10.7, la 18.11 à la 18.11.4, et la 19.0 à la 19.0.1.
• CVE-2026-2601, CVE-2026-2710, CVE-2026-6713, CVE-2026-8716 — quatre autres entrées couvertes par le même cycle de patch. Le bulletin GitLab détaille la portée par CVE ; le CERT-FR mentionne « déni de service à distance » et « contournement de la politique de sécurité » comme effets globaux de la salve.

CVE-2026-4868 est l'entrée la plus haute du cycle. La résolution d'identité erronée dans le runner Duo signifie qu'un attaquant disposant déjà d'un compte développeur peut faire exécuter du code IA — donc consommer du quota, déclencher des actions, accéder à des contextes — au nom d'un autre utilisateur de l'instance, y compris un mainteneur ou un compte de service.

Périmètre concerné

GitLab CE et EE auto-hébergés, sur les branches suivantes :

• 19.x antérieures à 19.0.1
• 18.11.x antérieures à 18.11.4
• toutes versions antérieures à 18.10.7 (l'avis couvre une rétro-portation jusqu'à la 11.5 sur CVE-2026-4868 et jusqu'à la 17.1 sur CVE-2026-1402)

GitLab.com tourne déjà sur les versions corrigées, selon l'éditeur. Les clients Dedicated sont mis à jour selon le calendrier opéré par GitLab.

Statut de l'exploitation

Aucun indicateur d'exploitation active n'est publié à ce stade — ni dans le bulletin GitLab, ni dans l'avis CERT-FR, ni par les éditeurs de threat intelligence. Aucun PoC public n'est référencé.

Le rythme habituel sur GitLab self-hosted reste néanmoins court : les CVE GitLab haute sévérité passent typiquement à l'exploitation opportuniste sous deux à quatre semaines après publication, et plusieurs entrées de la liste CISA Known Exploited Vulnerabilities en témoignent sur les deux dernières années.

Que faire

1. Mettre à jour vers 19.0.1, 18.11.4 ou 18.10.7 selon la branche déployée. Le bulletin GitLab référence chaque paquet (Linux package, Helm chart, image conteneur, source). Les déploiements Omnibus passent par apt/yum ; les déploiements Helm via helm upgrade.
2. Si vous opérez Duo AI, ne reportez pas le patch : CVE-2026-4868 est l'entrée la plus haute du lot et la seule pour laquelle le bulletin parle explicitement d'usurpation d'identité. Tant que le correctif n'est pas appliqué, désactivez les workflows Duo déclenchés par des comptes non administrateurs si la configuration le permet.
3. Auditer les rôles GitLab profitant du cycle de patch — Developer, Maintainer, accès aux runners. Plusieurs des CVE de la salve exigent un compte authentifié, et la combinaison « compte développeur + faille d'autorisation » reste l'enchaînement classique vers le vol de tokens CI/CD.
4. Surveiller les exécutions Duo AI inattendues sur les instances mises à jour avec retard : un workflow déclenché par un utilisateur A mais s'exécutant sous le contexte d'un utilisateur B laisse une trace asymétrique dans les journaux d'audit (audit_events / journal d'instance).
5. Vérifier la version effective après upgrade côté /-/admin et côté CI : un déploiement multi-nœuds peut conserver des sidecars en version antérieure le temps d'un redémarrage.

Contexte

C'est le deuxième cycle de correctifs majeur sur la branche 18 en moins de quatre semaines : le KB précédent (18.11.1 / 18.10.4 / 18.9.6) publié début mai couvrait déjà sept entrées, dont des contournements d'autorisation sur le forking de projets. Le rythme de patch GitLab — Patch Tuesday officieux toutes les deux semaines — concentre la dette de sécurité dans des fenêtres de mise à jour fréquentes mais courtes.

Côté français, GitLab est largement déployé chez les opérateurs essentiels et opérateurs de services essentiels (OIV/OSE) au sens NIS2 : une instance auto-hébergée concentre les secrets CI/CD, les jetons de déploiement et le code source. Un défaut d'identité comme CVE-2026-4868, exploité dans un contexte Duo où le runner exécute des commandes au nom d'un utilisateur arbitraire, entre directement dans la matrice de risque ANSSI. La fenêtre de patch est aussi celle des journaux — conservez-les.