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

Les faits

Fin avril 2026, des chercheurs en sécurité ont divulgué une vulnérabilité critique référencée CVE-2026-3854, affectant à la fois GitHub.com et les instances auto-hébergées de GitHub Enterprise Server. La faille permet à un utilisateur authentifié, disposant du simple droit de push sur n'importe quel dépôt accessible, de déclencher une exécution de code à distance sur l'infrastructure GitHub au moyen d'une opération git push spécialement forgée. Le score CVSS attribué place cette vulnérabilité au plus haut niveau de criticité, et l'ampleur du parc exposé aggrave encore le tableau : près de 88 % des instances Enterprise Server recensées n'avaient pas encore appliqué le correctif au moment de la publication. Pour les équipes de développement comme pour les RSSI, cet incident illustre la fragilité d'une chaîne d'intégration continue devenue le cœur névralgique du système d'information.

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 windows">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.