GitLab 19.1.2 / 19.0.4 / 18.11.7 : huit CVE dont un XSS EE 8,7 (CERTFR-2026-AVI-0850)

Le CERT-FR a publié le 9 juillet 2026 l'avis CERTFR-2026-AVI-0850 qui répercute le palier de sécurité GitLab du 8 juillet. Les versions 19.1.2, 19.0.4 et 18.11.7 (Community et Enterprise Edition) colmatent huit vulnérabilités — deux de sévérité haute, cinq moyennes, une basse. GitLab.com tourne déjà sur le palier patché. Les installations self-managed sont la cible à traiter. GitLab Dedicated n'est pas concerné.

Versions concernées

D'après la note de palier GitLab :

• GitLab CE/EE 19.1.x antérieures à 19.1.2
• GitLab CE/EE 19.0.x antérieures à 19.0.4
• GitLab CE/EE antérieures à 18.11.7

Les branches antérieures à 18.11 ne reçoivent pas de correctif dans ce palier. Si vous y êtes resté, la mise à jour vers une branche supportée est le seul chemin de remédiation.

CVE-2026-6896 — XSS haut niveau côté EE (CVSS 8,7)

CVE-2026-6896 est un cross-site scripting côté Enterprise Edition. Un attaquant disposant du rôle Developer — le rôle contributeur standard — peut injecter une charge script dans une vue affichée à un utilisateur privilégié via le composant de rendu du tableau de preuves de vulnérabilité de la Vulnerability Report. La faille tient à une sanitisation insuffisante des entrées utilisateur avant rendu dans ce composant.

Le pré-requis « Developer sur un projet » est la surface pratique de la faille : un compte de service compromis, un contributeur externe accepté sur un projet public, ou un ancien employé non désactivé sont les scénarios probables. La cible de la charge est ensuite un mainteneur, un auditeur sécurité ou un administrateur qui consulte la Vulnerability Report — précisément le profil dont on veut récupérer le cookie de session.

CVSS v3.1 : 8,7 (élevé).

CVE-2026-13320 — injection HTML dans le wiki (CVSS 7,3, CE et EE)

CVE-2026-13320 est une injection HTML dans le moteur de rendu du markup wiki, exploitable sur les deux éditions. La faille permet, sous conditions de privilèges élevés et d'interaction utilisateur, l'exécution de scripts arbitraires dans le contexte d'un autre utilisateur.

Le vecteur est donc l'écriture d'une page wiki piégée par un contributeur ayant les droits d'édition, et le déclenchement à la consultation par une victime. Sur les projets où le wiki est utilisé comme documentation technique partagée entre équipes, le taux de consultation est élevé et la victime type est un développeur senior ou un architecte — profils avec accès étendu à d'autres projets. CVSS v3.1 : 7,3 (élevé).

Autres vulnérabilités du palier

Le palier corrige également :

• CVE-2026-11827 (CVSS 4,9, EE) — protection insuffisante des identifiants dans les repository mirrors. Un utilisateur au rôle Maintainer peut récupérer les identifiants stockés d'autres utilisateurs.
• CVE-2026-8472 (CVSS 4,3, CE et EE) — contrôle d'accès défaillant sur les work items. Un utilisateur faiblement privilégié peut accéder à des métadonnées de projets privés.
• CVE-2026-7492 (CVSS 4,3, CE et EE) — un utilisateur non autorisé peut inférer l'existence de projets privés via l'affichage des discussions de commit.
• CVE-2026-13151 (CVSS 2,7, EE) — paramétrages de groupe modifiables au-delà du périmètre attendu par un utilisateur authentifié.
• CVE-2026-6352 (CVSS 2,7, EE) — un utilisateur au rôle Auditor peut modifier des enregistrements de conformité via une opération GraphQL mal contrôlée.
• CVE-2025-12506 (CVSS bas) — ambiguïté de résolution branche/tag pouvant conduire à un décalage entre le contenu affiché et le contenu téléchargé.

Statut d'exploitation

Aucune exploitation active n'est documentée à la date de l'avis pour l'une quelconque des huit vulnérabilités. Aucun PoC public. GitLab applique son embargo habituel : les détails techniques (issues HackerOne, tickets internes) sont rendus publics 30 jours après la sortie du correctif — soit autour du 7 août 2026 pour ce palier.

Cette fenêtre d'embargo est aussi la fenêtre de risque maximal côté self-managed : au 30e jour, la description technique de chaque bug devient publique, et les instances non patchées se retrouvent face à des exploits construits sur la base des mêmes issues HackerOne.

Que faire

1. Mettre à niveau dès aujourd'hui vers 19.1.2, 19.0.4 ou 18.11.7 selon la branche en production. La page des paliers de correctifs GitLab recense la chaîne complète des releases.
2. Auditer les comptes au rôle Developer et au-dessus sur les projets EE. CVE-2026-6896 est exploitable depuis ce périmètre. Les comptes à cibler en priorité : bots CI mal scopés, comptes de service historiques, contributeurs externes acceptés sur un projet et jamais retirés.
3. Vérifier l'utilisation des repository mirrors sur EE. CVE-2026-11827 expose les identifiants d'autres utilisateurs à un Maintainer malveillant. Si vous n'utilisez pas le miroir sur un projet, retirez les configurations résiduelles ; si vous l'utilisez, les identifiants concernés doivent être considérés comme potentiellement lus par un Maintainer avant la mise à jour et doivent être rotés.
4. Renforcer la CSP côté domaine GitLab si ce n'est pas déjà fait. La configuration Content-Security-Policy recommandée par GitLab est documentée dans le guide d'installation Omnibus ; les deux XSS haut niveau (CVE-2026-6896, CVE-2026-13320) perdent une part importante de leur efficacité opérationnelle sur une instance CSP correctement configurée.
5. Ne pas laisser dériver la branche 18.11. Elle reste supportée dans ce palier avec 18.11.7 mais elle est en fin de vie prévisible. Planifier la montée vers 19.0.x ou 19.1.x avant la prochaine rotation trimestrielle.
6. Périmètre NIS2 : l'avis CERTFR-2026-AVI-0850 est la référence à consigner dans le suivi du délai de traitement pour les entités régulées qui hébergent leur GitLab.

Contexte

C'est le troisième palier GitLab que le CERT-FR répercute en deux mois : après CERTFR-2026-AVI-0658 début juin (palier 19.0.1) et CERTFR-2026-AVI-0799 le 25 juin (palier 19.1.1), l'avis 0850 arrive deux semaines après le précédent. La cadence quasi-mensuelle de GitLab est stable ; ce qui change d'un cycle à l'autre, c'est la sévérité maximale. Cette fois : deux hauts niveaux et pas de critique.

Le point d'attention structurel : la Vulnerability Report — la vue qui centralise les résultats de scan SAST/DAST/SCA — est elle-même redevenue vecteur d'attaque via CVE-2026-6896. C'est la seconde fois en douze mois qu'un composant de la surface sécurité de GitLab devient le point d'entrée. Un défenseur qui exploite la Vulnerability Report comme tableau de bord central doit intégrer le fait que ce tableau lit du contenu attaquant-contrôlé — les preuves de vulnérabilité viennent des scanners, qui viennent des dépôts, qui viennent des contributeurs. Le principe de moindre privilège sur les comptes qui consultent la Vulnerability Report vaut aussi.