CVE-2026-3854 : RCE GitHub Enterprise Server via git push

Les faits

L'équipe de Wiz Research a divulgué CVE-2026-3854, une vulnérabilité critique d'exécution de code à distance (RCE) affectant GitHub Enterprise Server (GHES) ainsi que, temporairement, la plateforme github.com elle-même. Notée CVSS 8.7, la faille permet à n'importe quel utilisateur authentifié d'exécuter des commandes arbitraires sur les serveurs GitHub à partir d'une simple commande git push assortie d'une option spécialement forgée. L'exploitation ne réclame ni privilège d'administration, ni interaction d'un tiers : un compte standard disposant d'un droit d'écriture sur un dépôt suffit à compromettre l'hôte, avec à la clé un accès potentiel au code source, aux secrets CI/CD et aux jetons d'intégration. GitHub a corrigé la faille sur ses instances hébergées et publié des versions de maintenance pour GHES. Cet article détaille le mécanisme de la vulnérabilité, les versions concernées et les mesures de remédiation à appliquer sans délai.

La vulnérabilité réside dans babeld, un proxy Git interne développé par GitHub pour gérer les opérations push/pull à grande échelle. D'après l'analyse technique publiée par Wiz et reprise par GitHub Security Blog, le composant babeld copie les valeurs des options de push fournies par l'utilisateur (transmises via git push -o) dans un en-tête HTTP interne nommé X-Stat sans neutraliser les caractères spéciaux. Or, ce header utilise le point-virgule comme délimiteur de champs — le même caractère que l'attaquant peut injecter dans les valeurs utilisateur. La classification CWE-77 (improper neutralization of special elements in commands) résume la nature du défaut.

L'exploitation chaîne plusieurs injections successives. Premièrement, l'attaquant pousse une commande type git push -o "field1=value1;malicious_field=malicious_value" vers un dépôt qu'il possède. Deuxièmement, babeld concatène la valeur dans le header X-Stat, créant un champ supplémentaire que les services internes en aval interprètent comme une instruction légitime. Troisièmement, par chaînage de plusieurs valeurs injectées, les chercheurs Wiz ont démontré la possibilité d'override de variables d'environnement, le bypass du sandbox de pré-réception, et finalement l'exécution de commandes shell arbitraires sur les serveurs GitHub.

La chronologie de la divulgation illustre la maturité du programme bug bounty GitHub. Wiz a soumis le rapport le 4 mars 2026 ; GitHub a validé la vulnérabilité en quelques heures et déployé un correctif sur github.com le même jour à 19h00 UTC. Les versions corrigées de GHES (3.14.24, 3.15.19, 3.16.15, 3.17.12, 3.18.6, 3.19.3) ont été publiées dans les semaines suivantes, et la divulgation publique coordonnée a eu lieu le 28 avril 2026 — laissant aux clients enterprise environ 8 semaines pour patcher avant publication des détails techniques.

Le problème majeur est que, selon les données télémétrie de Wiz au moment de la divulgation, 88% des instances GHES exposées sur internet restaient non patchées. Cette inertie de patching est typique des plateformes on-premise critiques : les équipes DevOps craignent les régressions, doivent coordonner des fenêtres de maintenance avec les développeurs, et sous-estiment la rapidité d'intégration des vulnérabilités aux arsenaux malveillants. Trois semaines après la divulgation, un pourcentage significatif de GHES enterprise reste probablement vulnérable.

L'impact post-exploitation d'une RCE sur GHES dépasse largement le périmètre d'un simple serveur. GHES héberge le code source, les pipelines CI/CD (GitHub Actions), les secrets de déploiement, les SSH keys, et fréquemment les artefacts de build d'une organisation entière. Un attaquant compromettant un GHES peut : modifier le code source de production de l'entreprise, voler les tokens d'accès cloud (AWS, Azure, GCP) stockés en secrets, injecter du code malveillant dans les workflows Actions pour compromettre la chaîne logicielle, exfiltrer la totalité de la propriété intellectuelle logicielle. L'incident hypothétique se rapproche par sa gravité de l'affaire SolarWinds.

Aucune exploitation in-the-wild confirmée n'a été rapportée à ce jour selon GitHub Security, mais les conditions d'exploitation post-divulgation sont réunies. Les chercheurs en sécurité offensive sont nombreux à reconstituer des PoC à partir des indices publiés dans les blogs Wiz, Orca Security et CyCognito. Les bug bounty hunters et les opérateurs spécialisés dans la compromission de chaîne logicielle (groupes type APT41, Lazarus, Sandworm) ont historiquement priorisé les vecteurs GHES, Bitbucket et GitLab pour les attaques de supply chain.

À noter : CVE-2026-3854 nécessite l'authentification d'un compte utilisateur sur l'instance GHES, mais GHES permet l'auto-inscription dans de nombreuses configurations, et tout compte développeur compromis (phishing, fuite Stealer Logs sur le marché underground) peut servir de point de départ. La barrière d'authentification n'offre donc qu'une protection limitée face à un attaquant déterminé.

Impact et exposition

Les organisations exposées sont l'ensemble des clients GitHub Enterprise Server, soit plusieurs milliers d'entreprises mondiales — banques, assurances, grandes industries, administrations publiques, défense. github.com lui-même n'est plus concerné depuis le patch du 4 mars 2026. La condition d'exploitation se limite à l'accès en push sur n'importe quel dépôt de l'instance GHES, ce qui correspond au privilège minimal d'un développeur lambda.

La surface d'attaque effective dépend de la politique de l'instance GHES : (1) instances avec auto-inscription publique activée — tout internaute peut créer un compte et pousser ; (2) instances en SSO entreprise — tout employé peut potentiellement attaquer si son compte est compromis ; (3) instances air-gappées sans accès externe — surface réduite aux insiders et aux comptes compromis par latéralisation. Les deux premières configurations sont les plus courantes dans les déploiements enterprise.

L'impact en cas d'exploitation est de niveau "supply chain attack" : compromission du serveur de build et de la chaîne CI/CD. Les attaquants peuvent insérer du code malveillant dans les commits, les workflows GitHub Actions, ou les artefacts packagés, ce qui propage la compromission à tous les consommateurs en aval. Les conséquences peuvent inclure : vol massif de propriété intellectuelle, ransomware sur les dépôts (chiffrement et chantage), implants persistants dans les images Docker buildées, exfiltration des secrets de production (database credentials, API keys, tokens cloud).

À ce jour, aucune exploitation in-the-wild publique n'a été documentée, mais le risque résiduel sur les 88% d'instances GHES non patchées est massif. Les secteurs les plus exposés en France sont la défense (DGA, industriels), la finance (BNP, SocGen, AXA disposent d'instances GHES), les télécoms, et les ESN servicant des clients sensibles.

Recommandations immédiates

• Mettre à jour GHES vers 3.14.24, 3.15.19, 3.16.15, 3.17.12, 3.18.6 ou 3.19.3 selon votre branche — advisory : GitHub Enterprise Server Security Advisory CVE-2026-3854.
• Vérifier la version actuelle de votre GHES via l'interface admin (Site Admin → Maintenance) ou par l'API /api/v3/meta.
• Auditer les logs babeld et les logs Git pour des push contenant des options inhabituelles (caractère ; dans les valeurs -o) — IoC principal de l'exploitation.
• Restreindre l'auto-inscription publique si activée et exiger une approbation administrateur pour tout nouveau compte.
• Activer le SSO d'entreprise avec MFA obligatoire pour tous les comptes ayant accès au GHES.
• Auditer les secrets stockés dans les repositories et GitHub Actions : tout secret accessible doit être considéré comme compromis si l'instance était non patchée et exposée.
• Surveiller les workflows GitHub Actions pour des modifications non autorisées, particulièrement dans les fichiers .github/workflows/*.yml.