CVE-2026-3854 : un seul git push pour prendre GitHub.com

Les faits

Le 28 avril 2026, GitHub et l'équipe Wiz Research ont publie de maniere coordonnee les details de CVE-2026-3854, une vulnérabilité critique permettant a n'importe quel utilisateur disposant d'un droit de push sur un depot — y compris un depot qu'il a lui-meme cree — d'executer du code arbitraire sur les serveurs qui traitent l'operation git push. La faille porte un score CVSS 8.7 et touche aussi bien GitHub.com que les deploiements GitHub Enterprise Server (GHES) jusqu'a la version 3.19.1.

Le mécanisme d'exploitation est d'une simplicite deconcertante : la fonctionnalite git push options, concue pour transmettre des paramètres au serveur cote push, ne sanitisait pas correctement certains caracteres speciaux. Les valeurs fournies etaient embarquees telles quelles dans des metadonnees, ou un caractere injecte permettait de rompre le contexte d'execution et d'invoquer des commandes arbitraires cote serveur. La preuve de concept publiee par Wiz tient en une seule ligne : un git push avec une option X-Stat forgee.

La chronologie revele la rapidite de la reponse. Le 4 mars 2026, les chercheurs Wiz decouvrent la vulnérabilité et confirment l'execution de code a distance sur GHES 3.19.1. Le rapport est transmis a GitHub via le programme de bug bounty. Moins de deux heures apres reception, GitHub a valide le finding, deploye un correctif sur github.com et lance une investigation forensique. Le 10 mars, le CVE est attribue et le correctif GHES est mis a disposition. Le 28 avril marque la divulgation publique selon le calendrier convenu entre les deux équipes.

L'investigation forensique conduite par GitHub conclut a l'absence d'exploitation anterieure connue. Aucun indicateur ne suggere que la faille ait ete utilisee dans des operations malveillantes avant le correctif. Cette precision est importante : compte tenu de la simplicite de l'exploitation, n'importe quel attaquant disposant d'un compte GitHub aurait pu declencher l'attaque, sans privileges speciaux ni configuration particuliere.

L'impact theorique reste neanmoins considerable. GitHub fonctionne sur une architecture multi-tenant a backend partage : obtenir une exécution de code sur l'un des nœuds de stockage permet, en theorie, de lire les depots de millions d'organisations et d'utilisateurs heberges sur le meme nœud. La cross-tenant exposure, c'est-a-dire la fuite laterale entre clients d'une meme infrastructure mutualisee, est precisement le scenario que GitHub tente d'empecher avec ses isolations internes. L'exploitation de CVE-2026-3854 court-circuitait ces garanties.

Cote GitHub Enterprise Server, les administrateurs doivent verifier qu'ils tournent au minimum sur la version corrigee annoncee le 10 mars 2026. Les versions vulnerables incluent toutes les branches 3.x jusqu'a 3.19.1. Les organisations utilisant GHES dans des environnements air-gappes ou avec des cycles de mise a jour longs constituent aujourd'hui le perimetre residuel a risque, puisque la divulgation publique fournit desormais des indices suffisants pour reconstruire un exploit.

Wiz Research precise dans son post-mortem que la vulnérabilité s'inscrit dans une lignee plus large d'injections via paramètres utilisateur insuffisamment echappes dans des contextes de metadonnees. Les options git push, comme nombre de mécanismes d'extension de protocoles, n'avaient pas fait l'objet d'une revue de sanitization aussi rigoureuse que les chemins d'entree traditionnels (HTTP API, webhooks). Le correctif consiste en un echappement strict des caracteres de controle dans les metadonnees générées a partir des push options.

Impact et exposition

Pour les utilisateurs de GitHub.com, l'exposition est desormais nulle puisque le correctif est en production depuis le 4 mars. Aucune action n'est requise cote client. Les organisations qui auraient des doutes sur d'eventuels acces anormaux sur leurs depots entre janvier et mars peuvent solliciter GitHub Support pour un audit, mais GitHub a publiquement declare n'avoir trouve aucune trace d'exploitation.

Les deploiements GHES sont la zone a surveiller. Les versions 3.x anterieures au correctif de mars sont exploitables par tout utilisateur authentifie disposant d'un droit de push — soit, dans la plupart des installations Enterprise, plusieurs centaines a plusieurs milliers de comptes internes. Les environnements multi-équipes avec delegation forte des droits sont particulierement exposes, puisque la barriere d'acces initiale (un compte avec droit de push sur n'importe quel depot) est faible.

Recommandations

• Verifier la version de GHES et appliquer le patch publie le 10 mars 2026 si ce n'est pas deja fait.
• Auditer les logs d'acces aux serveurs GHES sur la periode janvier-mars 2026 pour détecter d'eventuels processus enfants anormaux issus du daemon git.
• Restreindre les droits de push aux depots critiques au strict nécessaire et privilegier les pull requests avec revue obligatoire.
• Activer GitHub Enterprise audit log streaming vers un SIEM pour conserver la tracabilite des operations git push.