GitHub CVE-2026-3854 : RCE en un git push, 88 % vulnérables

Les faits

Des chercheurs ont divulgué fin avril 2026 une vulnérabilité critique référencée CVE-2026-3854 affectant GitHub.com et GitHub Enterprise Server. La faille permet à un utilisateur authentifié, disposant simplement d'un droit de push sur n'importe quel dépôt accessible, de déclencher une exécution de code à distance sur l'infrastructure GitHub via une opération git push spécialement formée. La CVSS est fixée à 8.7, mais l'impact systémique est majeur car la chaîne d'exploitation ne nécessite ni privilèges élevés ni interaction utilisateur côté défenseur.

La vulnérabilité réside dans le pipeline de traitement côté serveur des opérations Git. Lors d'un push, GitHub exécute en arrière-plan une série de hooks et de validations sur les objets Git reçus, notamment pour la détection de secrets, l'application des branch protection rules et la mise à jour des métadonnées des PR. Selon le rapport publié par les chercheurs et relayé par The Hacker News, c'est dans ce pipeline qu'une donnée contrôlée par l'attaquant — un nom de référence ou une métadonnée d'objet — est interpolée dans un appel système sans neutralisation suffisante, permettant l'injection de commandes arbitraires sur le runner traitant l'opération.

Sur GitHub Enterprise Server auto-hébergé, l'exploitation donne un accès au compte technique sous lequel tourne le service git, ce qui équivaut à terme à la compromission du serveur entier — le même processus a accès aux dépôts, aux secrets stockés en clair en base et aux clés de signature de releases. Sur la plateforme GitHub.com SaaS, GitHub a indiqué avoir corrigé la faille avant la publication et procédé à une revue rétroactive des journaux pour identifier toute exploitation antérieure ; aucune compromission n'a été divulguée publiquement à ce stade.

Le scan opportuniste mené par les chercheurs sur des milliers d'instances GitHub Enterprise Server exposées sur Internet a montré que 88 % des serveurs n'étaient pas patchés au moment de la divulgation. La majorité tournait sur les branches 3.12 et 3.13, deux versions encore en support à la date de l'annonce. Une partie significative — environ 14 % de la population scannée — était sur des versions 3.10 et 3.11, hors support, donc non corrigées.

GitHub a publié simultanément trois versions de correction : 3.13.4, 3.14.3 et 3.15.1. La note de sécurité accompagnant les versions précise que l'exploitation laisse une trace observable dans les logs d'audit du service, sous la forme d'opérations git-receive-pack avec des références anormalement longues ou contenant des séquences de contrôle. Les équipes ayant un SIEM connecté à GitHub Enterprise sont invitées à rejouer les 90 derniers jours sur cette signature pour détecter d'éventuelles tentatives passées.

L'angle d'attaque le plus concret pour un adversaire est le suivant : compromettre un compte développeur via du phishing ou un token leaké, puis utiliser ce compte pour pousser sur n'importe quel fork ou dépôt en écriture afin de déclencher la RCE et pivoter sur le serveur GitHub Enterprise interne de la cible. Dans les organisations qui hébergent leur propre GitHub Enterprise, ce serveur est souvent un point de centralisation extrêmement sensible : il contient le code source, les pipelines CI/CD, les credentials de déploiement et parfois les artefacts de release signés. Sa compromission est une catastrophe.

L'écho médiatique a été immédiat car la cible — la chaîne logicielle elle-même — fait suite à la série d'incidents Shai-Hulud, mini Shai-Hulud sur SAP CAP, et plus largement à la prise de conscience que l'écosystème de développement est devenu une cible de premier ordre pour les attaquants étatiques et financiers. La supply chain DevSecOps est désormais autant un actif stratégique que la production elle-même.

Impact et exposition

Sont concernées toutes les instances GitHub Enterprise Server auto-hébergées en versions 3.12 à 3.15.0. Les organisations utilisant GitHub.com SaaS dépendent du correctif déployé par GitHub côté serveur et n'ont rien à patcher localement, mais doivent vérifier qu'aucun token de leur tenant n'a été utilisé suspicieusement dans les 30 jours précédant la divulgation.

Recommandations

• Migrer immédiatement vers 3.13.4, 3.14.3 ou 3.15.1 selon la branche déployée. Pour les instances en 3.10 ou 3.11, planifier en urgence une mise à niveau majeure.
• Restreindre l'accès réseau au GitHub Enterprise interne aux seuls réseaux d'entreprise et VPN — un GitHub Enterprise exposé sur Internet est un risque structurel.
• Activer l'audit log streaming vers un SIEM et rejouer les 90 derniers jours à la recherche d'opérations git-receive-pack avec références anormales.
• Faire tourner les secrets stockés (secrets Actions, tokens d'intégration, clés SSH déployées) en cas de doute sur l'exposition.