CVE-2026-3854 : exécution de code à distance sur GitHub via un simple git push

Le 4 mars 2026, des chercheurs de Wiz Research — filiale de Google depuis le rachat finalisé à 32 Md$ le 11 mars 2026 — ont découvert une vulnérabilité critique dans le pipeline interne de git push de GitHub. Divulguée publiquement le 28 avril, elle a reçu la cote CVE-2026-3854 avec un score CVSS de 8,7.

Le mécanisme : une injection dans l'en-tête X-Stat

Lors d'un git push, le démon interne de GitHub, babeld (le proxy git), construit un en-tête X-Stat contenant des paires clé-valeur délimitées par des points-virgules. Ces valeurs sont transmises aux services backend pour contrôler le comportement du hook de pré-réception.

Le problème : les valeurs des push options fournies par l'utilisateur étaient copiées dans cet en-tête sans échappement du point-virgule, le délimiteur de champ. Le parseur en aval appliquait une logique « last-write-wins » : un champ injecté en fin d'en-tête écrasait les valeurs légitimes.

# Exploitation conceptuelle
git push --push-option="x;rails_env=test;custom_hooks_dir=/tmp/evil;repo_pre_receive_hooks=..." origin main

Chaîne d'exploitation en trois injections

Les chercheurs de Wiz ont enchaîné trois injections successives pour atteindre l'exécution de code :

1. rails_env=test — sortie du sandbox de production
2. custom_hooks_dir=/tmp/attacker — redirection du répertoire des hooks git
3. repo_pre_receive_hooks=<entrée crafté> — déclenchement d'une traversée de chemin exécutant une commande arbitraire sous l'identité de l'utilisateur git

Le tout ne nécessitait qu'un accès push standard à un dépôt — aucun privilège administrateur, aucune interaction utilisateur supplémentaire.

Impact : cross-tenant sur des millions de dépôts

Sur GitHub.com, l'exécution de code aboutissait sur des nœuds de stockage partagés contenant des millions de dépôts appartenant à d'autres organisations. L'équipe de Wiz a confirmé avoir accédé à ces nœuds sans jamais toucher de données tierces. Le risque réel en cas d'exploitation malveillante : lecture ou modification de secrets, code source, packages.

Pour les instances GitHub Enterprise Server (GHES) auto-hébergées, l'attaquant pouvait obtenir une compromission complète du serveur, avec accès à tous les dépôts et secrets internes.

Timeline et correctif

À la date de divulgation, selon les données de Wiz, 88 % des instances GHES publiquement accessibles n'avaient pas encore été patchées.

Ce qu'il faut faire

• GitHub.com : aucune action requise, le correctif est déployé depuis le 4 mars.
• GitHub Enterprise Server : mettre à jour vers l'une des versions patchées : 3.14.24, 3.15.19, 3.16.15, 3.17.12, 3.18.6, ou 3.19.3 (et supérieur).
• Audit : vérifier /var/log/github-audit.log pour des push operations contenant des caractères spéciaux inhabituels dans les push options — indicateur potentiel d'une exploitation antérieure.

Ce que cette faille révèle

CVE-2026-3854 illustre un pattern classique dans les systèmes distribués : une frontière de confiance implicite entre composants internes. Le service babeld faisait confiance aux valeurs transmises sans les valider, parce qu'elles étaient supposées provenir de composants contrôlés — mais le canal d'entrée (les push options) était exposé aux utilisateurs.

La rapidité de la réponse côté GitHub.com (75 minutes) est remarquable. En revanche, le taux de mise à jour des instances auto-hébergées (12 % après 7 semaines) rappelle que la sécurité d'une supply chain dépend du maillon le plus lent.

GitHub Advisory GHSA-64fw-jx9p-5j24↗ · Wiz Research↗ · GitHub Blog↗ · Help Net Security — 88 % des instances vulnérables↗