3 min de lecture
CVE-2026-3854 : une faille RCE dans GitHub expose des millions de dépôts via git push
Une vulnérabilité CVSS 8.7 dans GitHub Enterprise Server permet l'exécution de code à distance via une simple commande git push. 88 % des serveurs auto-hébergés restent non patchés.
CVE-2026-3854 : une faille RCE dans GitHub expose des millions de dépôts via git push
Une vulnérabilité critique dans GitHub Enterprise Server a été rendue publique le 28 avril 2026 par les chercheurs de Wiz Research. Elle permettait à tout utilisateur authentifié d'exécuter du code arbitraire sur les serveurs GitHub via une seule commande git push. GitHub.com est patché depuis mars. La majorité des instances auto-hébergées restent, elles, toujours exposées.
Une injection dans le pipeline git push
La faille réside dans babeld, le service proxy interne de GitHub qui gère les opérations git push. Ce proxy collecte des métadonnées et les transmet aux services back-end via un en-tête HTTP personnalisé nommé X-Stat. Le problème : les valeurs d'option de push fournies par l'utilisateur n'étaient pas correctement assainies avant d'être incluses dans cet en-tête.
En injectant un caractère délimiteur spécifique dans les options de push, un attaquant pouvait ajouter des champs de métadonnées supplémentaires et déclencher l'exécution de commandes arbitraires sur l'infrastructure back-end. Le score CVSS est de 8.7. La seule condition requise est de disposer d'un accès push sur un dépôt hébergé sur l'instance cible, sans nécessité de droits administrateurs. Il n'existe pas de contournement possible sans patcher : la surface d'attaque est inhérente au protocole de push.
GitHub.com patché en deux heures, GHES toujours en retard
Wiz Research a découvert la vulnérabilité le 4 mars 2026 et l'a signalée à GitHub le jour même. GitHub a déployé un correctif sur GitHub.com en moins de deux heures, sans qu'aucune exploitation ne soit détectée sur la plateforme publique. GitHub Enterprise Server (GHES), qui s'installe sur les propres serveurs des entreprises, exige en revanche une mise à jour manuelle.
La divulgation publique du 28 avril révèle que 88 % des instances GHES n'avaient toujours pas appliqué le correctif. Des millions de dépôts privés hébergés par des équipes de développement dans les secteurs de la finance, de la santé et des infrastructures critiques étaient potentiellement accessibles à tout contributeur disposant d'un accès push. Les versions corrigées sont GHES 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.8, 3.19.4 et ultérieures. Cette situation rappelle la faille SSRF dans LMDeploy, exploitée moins de 13 heures après sa divulgation publique, soulignant à quel point les outils d'infrastructure pour développeurs sont devenus une cible prioritaire.
Ce que ça signifie pour vous
Pour les utilisateurs de GitHub.com, aucune action n'est requise. Pour les équipes qui opèrent une instance GHES, la priorité est de vérifier la version installée et de passer en 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.8 ou 3.19.4 au minimum, sans attendre.
Cette vulnérabilité s'inscrit dans une série d'attaques touchant directement les outils utilisés par les développeurs. L'attaque de la chaîne d'approvisionnement sur LiteLLM et PyPI avait exposé des données d'entraînement de grands laboratoires. La faille RCE dans LeRobot de Hugging Face, divulguée le 29 avril et toujours non corrigée, présente le même profil de risque. Le code source, les modèles et les pipelines de déploiement constituent désormais une surface d'attaque aussi critique que les applications elles-mêmes.
Sources : Wiz Research · The Hacker News · Help Net Security · Bleeping Computer