CVE-2026-3854 : RCE GitHub Enterprise via git push (CVSS 8.7)

Les faits

La vulnérabilité CVE-2026-3854, publiée le 28 avril 2026 par les équipes de recherche Wiz et l'équipe sécurité de GitHub, frappe au cœur même du pipeline d'ingestion git push de GitHub.com et de son pendant on-premise GitHub Enterprise Server. Évaluée à 8.7 sur l'échelle CVSS v3.1, la faille permet à tout utilisateur disposant d'un accès en écriture à un dépôt - donc en pratique tout collaborateur authentifié - d'exécuter des commandes arbitraires sur les serveurs internes de GitHub via une simple commande git push, sans aucun outil exotique ni privilège administrateur.

La chronologie de la découverte est éloquente sur la criticité du correctif. Le 4 mars 2026, les chercheurs de Wiz signalent la vulnérabilité à GitHub. Le même jour, à 19 h 00 UTC, GitHub déploie un correctif sur GitHub.com. Le 10 mars 2026, l'identifiant CVE-2026-3854 est attribué et le correctif pour GitHub Enterprise Server est livré dans la version 3.19.3. La divulgation publique coordonnée intervient sept semaines plus tard, le 28 avril 2026, laissant aux administrateurs d'instances on-premise un délai très court pour patcher avant que les détails techniques ne soient connus de la communauté offensive.

Sur le plan technique, la racine du bug se trouve dans le composant babeld, le service interne qui orchestre les opérations git côté serveur chez GitHub. Lors d'un git push, le client peut transmettre des push options - des paires clé-valeur arbitraires destinées aux hooks ou aux outils CI/CD. Ces valeurs étaient recopiées telles quelles par babeld dans un en-tête HTTP interne nommé X-Stat, qui sert de canal de communication entre les microservices backend. Le format de cet en-tête utilise le point-virgule comme délimiteur de champs. Or, babeld ne filtrait ni n'échappait ce caractère lorsqu'il provenait des push options fournies par l'utilisateur.

Le scénario d'exploitation est d'une simplicité déconcertante. Un attaquant disposant des droits de push sur n'importe quel dépôt - public, privé ou interne, peu importe - construit une push option contenant un point-virgule suivi de champs forgés. Au moment où babeld assemble l'en-tête X-Stat, ces champs supplémentaires sont injectés et interprétés en aval par d'autres services internes comme s'ils provenaient légitimement de l'infrastructure. En manipulant judicieusement ces métadonnées, l'attaquant détourne la logique de routage et de stockage pour obtenir une exécution de commandes arbitraires sur les nœuds de stockage partagés (shared storage nodes) chez GitHub.com, ou sur le serveur applicatif lui-même dans le cas de GitHub Enterprise Server.

L'impact est radicalement différent selon la cible. Sur GitHub.com, l'architecture multi-tenant signifie qu'une exécution de code sur un nœud de stockage partagé donne accès, théoriquement, aux dépôts de millions d'autres clients hébergés sur la même machine physique. C'est un scénario de cross-tenant exposure majeur, du même ordre de gravité que les vulnérabilités hyperviseur en environnement cloud. Sur GitHub Enterprise Server, qui est typiquement déployé en single-tenant chez le client, l'impact est plus localisé mais souvent plus dramatique : compromission complète du serveur, accès à tous les dépôts hébergés, exfiltration de tous les secrets stockés (clés SSH, tokens d'accès, variables CI/CD), et pivot probable vers le reste du système d'information de l'entreprise.

Selon les déclarations conjointes de GitHub et Wiz, aucune trace d'exploitation in-the-wild n'a été détectée. Toutes les occurrences identifiées dans les logs correspondent aux tests menés par les chercheurs Wiz dans le cadre du programme de divulgation responsable. Cependant, depuis la publication des détails techniques par Wiz et The Hacker News fin avril, la communauté offensive dispose d'informations suffisantes pour reproduire l'exploit. Un proof-of-concept détaillé circule désormais dans les milieux red team et bug bounty, ce qui rend la fenêtre d'exploitation post-disclosure particulièrement étroite pour les administrateurs n'ayant pas encore patché.

Le chiffre publié par Help Net Security le 29 avril 2026 a fait grand bruit dans la communauté DevSecOps : 88 % des instances GitHub Enterprise Server auto-hébergées exposées sur Internet n'avaient toujours pas appliqué la mise à jour 3.19.3 au moment de la divulgation publique. Cela représente potentiellement plusieurs milliers de serveurs vulnérables dans des entreprises Fortune 500, des laboratoires de recherche, des agences gouvernementales et des éditeurs de logiciels critiques. La criticité réelle dépasse largement le score CVSS de 8.7 lorsqu'on considère la nature des données stockées : code source propriétaire, clés cryptographiques, pipelines de déploiement vers la production.

Cette vulnérabilité s'inscrit dans une tendance préoccupante observée en 2026 : les attaques sur la chaîne d'approvisionnement logicielle ne ciblent plus seulement les paquets npm ou PyPI mais remontent vers les plateformes d'hébergement de code elles-mêmes. CVE-2026-3854 illustre que même les acteurs les plus matures peuvent introduire des failles d'injection triviale dans des composants critiques, simplement parce qu'un délimiteur n'a pas été échappé. La leçon dépasse GitHub : tout pipeline qui recopie des entrées utilisateur dans des en-têtes inter-services est suspect par construction.

Impact et exposition

L'exposition est massive et stratifiée. Pour GitHub.com, le correctif a été déployé en quelques heures par GitHub - les utilisateurs n'ont rien à faire et la fenêtre d'exposition s'est limitée à la période antérieure au 4 mars 2026. En revanche, pour GitHub Enterprise Server, la responsabilité du patch incombe à chaque administrateur d'instance, ce qui explique le taux de couverture désastreux relevé par Wiz fin avril : sur les serveurs GHES exposés sur Internet, seuls 12 % avaient migré vers la 3.19.3 au moment où les détails techniques ont été publiés.

Les conditions d'exploitation sont triviales : il suffit de disposer d'un compte avec droits de push sur n'importe quel dépôt hébergé sur l'instance ciblée. Dans la plupart des entreprises, cela inclut tous les développeurs internes, les sous-traitants ayant accès à des dépôts privés, voire les contributeurs externes sur les dépôts ouverts. Le coût pour un attaquant d'obtenir un compte avec ce niveau de privilèges est faible : phishing ciblé, credentials stuffing, ou compromission préalable d'un poste développeur via un infostealer suffisent.

La surface d'attaque est particulièrement préoccupante pour les organisations qui hébergent leur propre instance GHES en pensant gagner en confidentialité. Beaucoup de ces déploiements sont accessibles via VPN ou exposés sur Internet pour faciliter le télétravail et l'intégration de partenaires. Une exploitation réussie donne à l'attaquant les clés du royaume : code source, secrets, runners CI/CD, accès aux registries de conteneurs internes. Le scénario typique post-compromission consiste à injecter un backdoor dans une dépendance interne ou un workflow GitHub Actions, transformant la compromission ponctuelle en compromission de la chaîne de build.

À ce jour, GitHub indique n'avoir détecté aucune exploitation sauvage, mais cette absence ne durera probablement pas. La publication conjointe de Wiz contient suffisamment de détails sur le format de l'en-tête X-Stat et le comportement de babeld pour qu'un PoC fonctionnel soit reconstruit en quelques heures par un chercheur compétent. Les administrateurs GHES doivent considérer la vulnérabilité comme exploitée par défaut et planifier un audit forensique.

Recommandations immédiates

• Mettre à jour GitHub Enterprise Server vers la version 3.19.3 ou ultérieure (correctif référencé dans le GitHub Enterprise Server Security Advisory du 10 mars 2026).
• Pour les versions plus anciennes en LTS, vérifier qu'un patch de sécurité rétroporté est disponible dans la branche correspondante avant de planifier une migration majeure.
• Auditer les logs babeld et les requêtes git push depuis le 4 mars 2026 à la recherche de push options contenant le caractère point-virgule, qui constitue le marqueur d'exploitation principal.
• Restreindre temporairement les push options via la configuration receive.advertisePushOptions ou des hooks pre-receive jusqu'à application du correctif.
• Faire tourner toutes les credentials et secrets stockés sur l'instance GHES en cas de doute sur une exploitation antérieure : tokens d'accès personnels, clés de déploiement, secrets GitHub Actions.
• Surveiller les sorties anormales depuis les nœuds GHES vers Internet, signe d'une éventuelle exfiltration post-exploitation.