BRIEFING SÉCURITÉ · 23.09.2026 DEENFRES

Pratique & Mise en œuvre

Un simple git-push suffit à exploiter les serveurs GitHub Enterprise

Par Tobias Massow · 1 mai 2026 · 7 min de lecture

Le 28 avril 2026, Wiz Research et GitHub ont publié les détails concernant CVE-2026-3854 : une vulnérabilité de commande d’injection dans GitHub Enterprise Server permet à tout utilisateur authentifié avec accès de push à un référentiel de lancer du code arbitraire sur le serveur avec un seul git push. 88 pour cent des instances auto-hébergées étaient non correctées au moment de la divulgation.

Les points clés en bref

  • CVSS 8.7 – un seul git push suffit. Tout utilisateur avec accès de push à un référentiel – y compris celui qui a été créé – peut exécuter des commandes arbitraires sur le serveur GitHub Enterprise. Pas de kit d’exploitation, seulement un client git standard.
  • Injection de commande dans le traitement des options de push. Les valeurs des options de push n’étaient pas suffisamment nettoyées avant le traitement. Un attaquant peut injecter des champs de métadonnées supplémentaires dans les en-têtes internes à travers un caractère de délimiteur.
  • GitHub.com a été correcté en moins d’une heure. Wiz Research a découvert la faille le 4 mars 2026 et a signalé GitHub le même jour. Le correctif a été déployé sur GitHub.com le 4 mars. Les correctifs pour GHES ont été publiés le 10 mars. La divulgation publique a eu lieu le 28 avril 2026.
  • Correctifs disponibles pour toutes les versions de GHES prises en charge. 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.7, 3.19.4, 3.20.0 et versions ultérieures. Les utilisateurs d’anciennes versions ne bénéficient plus d’un support.

Explication de l’attaque : Pourquoi un git push suffit pour l’exécution de code

Les opérations git push supportent des options de push nommées, qui sont des paires clé-valeur définies par l’utilisateur transmises en tant que métadonnées au push. GitHub Enterprise Server a traité ces valeurs dans un protocole interne sans escaper correctement le caractère de délimiteur. Comme ce caractère peut être présent dans l’entrée utilisateur, des options de push craftées peuvent injecter des champs d’en-tête supplémentaires dans la communication interne.

Le résultat est l’exécution de code sur le serveur, non dans le référentiel, mais dans le service backend qui traite le push. Wiz Research décrit l’attaque comme étant reproduitable avec un client git standard. Pas de logiciel spécifique, pas de faille préexistante, pas d’autorisation spéciale autre qu’un accès de push à un référentiel.

Ce scénario d’attaque a une barrière faible : tout contributeur externe, tout employé avec accès au référentiel, tout compte compromis peut exploiter cette faille. Dans les environnements d’entreprise avec des déploiements à grande échelle de GitHub auto-hébergé, le champ d’action est considérable.

Chronologie de la divulgation : Qu’est-il arrivé entre mars et avril

4 mars 2026 : Wiz Research a découvert et a signalé la faille à GitHub. GitHub a déployé un correctif en moins d’une heure sur GitHub.com.

10 mars 2026 : Les correctifs pour toutes les versions de GitHub Enterprise Server prises en charge ont été publiés : 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.7, 3.19.4, 3.20.0. CVE-2026-3854 a reçu une note CVSS 8.7.

28 avril 2026 : Divulgation publique après une divulgation coordonnée. À ce moment, selon une recherche de Help Net Security, 88 pour cent des instances auto-hébergées étaient encore non correctées – soixante-huit jours après la disponibilité des correctifs.

88 pour cent non correctés. Soixante-huit jours après la publication des correctifs pour GHES, presque toutes les instances auto-hébergées étaient encore en version vulnérable. C’est pas un cas isolé, c’est le statut normal de l’infrastructure Git d’entreprise.

Quelles actions les équipes de sécurité dans la région DACH doivent entreprendre immédiatement

1. Vérifier la version GHES immédiatement. Les versions minimales mises à jour avec des correctifs : 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.7, 3.19.4, 3.20.0. Toute version antérieure à 3.14 ou inférieure n’est pas prise en charge et doit être mise à jour.

2. Examiner les droits d’accès au référentiel. Qui a accès en écriture à quels référentiels ? Contributeurs externes, comptes de service obsolètes, accès temporaires ? Chaque compte est un potentiel chemin d’attaque, indépendamment de l’état de confidentialité du référentiel.

3. Examiner les anomalies dans les journaux de serveur. GitHub fournit des journaux pour les opérations de push. Les valeurs d’option de push inhabituelles, les pushes d’adresses IP inconnues ou à des heures inhabituelles devraient faire l’objet d’une vérification manuelle.

4. Examiner les contrôles de la couche réseau. Le port administrateur GHES (8443) et les points de terminaison de service internes ne doivent pas être accessibles depuis l’Internet public. Cela ne réduit pas le chemin d’attaque à zero, mais il renforce la barrière contre les attaquants externes.

Questions fréquentes sur CVE-2026-3854

Chaque question est verrouillée. Un clic déverrouille la réponse.

Est-ce que CVE-2026-3854 affecte aussi GitHub.com ou seulement les instances auto-hébergées ?

Il affecte les deux. GitHub.com a déployé un correctif dans les heures suivant le dévoilement responsable par Wiz Research le 4 mars 2026. Les utilisateurs de GitHub.com sont protégés depuis le 4 mars. Le risque est principalement pour les organisations qui hébergent leur propre instance de GitHub Enterprise Server et qui n’ont pas encore mis à jour vers les versions correctées.

Doit-on considérer tous les référentiels sur un serveur GHES comme compromis ?

Cela dépend de savoir si la faille a été activement exploitée. Un correctif ferme le chemin d’attaque, mais ne résout pas une compromission antérieure. Les organisations avec du code sensible (Infrastructure as Code, mots de passe dans les référentiels, configurations de pipelines CI/CD) devraient examiner leur historique Git et les journaux de serveur pour des activités suspects depuis mars 2026. En cas de doute, initier un processus d’intervention sur les incidents.

Pouvons-nous utiliser GitHub Actions ou des pipelines CI/CD pour exploiter cette faille ?

Oui. Toute composante automatisée qui exécute des opérations de push Git – workflows Actions, runners CI/CD, scripts de déploiement – est un potentiel chemin d’attaque si elle s’exécute sur une instance GHES vulnérable. Particulièrement pertinents : les runners externes qui ont accès à plusieurs référentiels et dont les informations d’identification pourraient être compromises.

Quelle est la différence avec la faille de Supply-Chain dans l’action GitHub Action de Bitwarden CLI ?

CVE-2026-3854 est une faille côté serveur – l’attaquant cible directement le serveur GitHub Enterprise Server. La faille de l’action GitHub Action de Bitwarden CLI est une attaque de Supply-Chain via des dépendances externes dans les pipelines. Toutes deux sont critiques, mais nécessitent des mesures de protection différentes : gestion des correctifs pour CVE-2026-3854, lienage des dépendances et processus SBOM pour les risques de Supply-Chain.

Les choix de la rédaction

À lireLiteLLM CVE-2026-42208 : accès non autorisé aux bases de donnéesÀ lireViolation BePrime : absence de MFA à l’origine d’une fuite de donnéesÀ lireAttaque de la chaîne d’approvisionnement via GitHub Actions contre Bitwarden CLI

Plus du réseau MBF Media

Digital ChiefsGartner alerte les CIO sur la pénurie de semi-conducteurscloudmagazinModèles OpenAI sur AWS : Les équipes DACH en transitionMyBusinessFutureAI Act de l’UE à partir d’août 2026 : ce que les PME doivent étiqueter maintenant

Pour aller plus loin

Un magazine d'Evernine Media GmbH