Faille critique GitHub : une simple commande git push permettait d’exécuter du code
Des chercheurs en sécurité de Wiz ont découvert une vulnérabilité critique dans l’infrastructure interne de GitHub, permettant à n’importe quel utilisateur authentifié d’exécuter du code arbitraire sur les serveurs de la plateforme, le tout avec une seule commande git.
Table des matières
Un git push. C’est, à peu près, tout ce qu’il fallait.
Pas d’exploit sophistiqué, pas de vulnérabilité zero-day dans une librairie obscure. Juste une commande que des millions de développeurs tapent des dizaines de fois par jour, et qui, jusqu’au 4 mars 2026, pouvait suffire à prendre le contrôle de serveurs internes de GitHub, potentiellement accédant ainsi aux dépôts privés de n’importe quelle organisation hébergée sur la plateforme.
La faille, référencée CVE-2026-3854, a été découverte par l’équipe Wiz Research et rendue publique le 28 avril. Elle touche deux cibles distinctes : GitHub.com, la plateforme cloud utilisée par des centaines de millions de développeurs dans le monde, et GitHub Enterprise Server (GHES), la version auto-hébergée utilisée par les grandes entreprises et administrations.
Comprendre le problème
Pour comprendre la faille, il faut d’abord savoir ce qui se passe en coulisses quand vous poussez du code sur GitHub. Votre commande ne va pas directement dans un dépôt ; elle traverse une chaîne de plusieurs services internes, chacun écrit dans un langage différent, qui échangent des informations via un header HTTP interne, appelé X-Stat.
Ce header fonctionne comme un formulaire contenant des paires « clé=valeur » séparées par des points-virgules : la politique de fichiers trop volumineux, les règles de nommage des branches, les droits de l’utilisateur… tout transite par là.
Le premier service de la chaîne, nommé « babeld », construit ce header après avoir vérifié l’identité de l’utilisateur. Les services suivants lui font confiance les yeux fermés.
Problème : quand ce fameux babeld intègre des push options dans ce header, c’est-à-dire des chaînes arbitraires que l’utilisateur peut passer via la commande git push -o, il ne filtre pas les points-virgules. Or, le point-virgule joue précisément le rôle de délimiteur dans le header, permettant ainsi à un attaquant d’injecter de nouveaux champs en glissant un point-virgule dans sa push option. Quand une clé est dupliquée, la dernière valeur l’emporte et l’attaquant peut donc écraser n’importe quel paramètre de sécurité défini en amont.
Les chercheurs de Wiz ont identifié plusieurs champs internes sensibles pouvant être injectés de cette manière. Trois d’entre eux, combinés, ouvrent la voie à une exécution de code arbitraire à distance complète sur l’infrastructure interne de GitHub.
Des millions de dépôts à portée
Sur GitHub Enterprise Server, l’exploitation était directe. Sur GitHub.com, une subtilité supplémentaire entrait en jeu : les custom hooks sont désactivés par défaut sur la plateforme cloud. Cependant, Wiz a découvert qu’un flag supplémentaire dans le même header, contrôlant l’activation du mode Enterprise, était lui aussi injectable via le même mécanisme. Une injection de plus, et la chaîne complète fonctionnait.
Ce qui rend cette découverte notable dépasse la vulnérabilité elle-même. Wiz souligne que l’analyse a été rendue possible par du reverse engineering augmenté par IA, via un outil appelé IDA MCP. Analyser les binaires compilés et propriétaires qui constituent l’infrastructure interne de GitHub était auparavant trop coûteux en temps pour être systématique. Avec ces outils, les chercheurs ont pu reconstruire les protocoles internes et tracer le flux des données utilisateur à travers toute la chaîne, rapidement.
GitHub.com a reçu un correctif six heures après le signalement, le 4 mars 2026. Pour GHES, des patches ont été publiés pour toutes les versions supportées. La mise à jour vers la version 3.19.3 ou ultérieure est la seule action à effectuer. Au moment de la divulgation publique, 88 % des instances GHES recensées par Wiz étaient encore vulnérables.
Source : Wiz Research.
