Une simple commande pour compromettre un serveur GitHub ? C’est possible grâce à l’exploitation de la nouvelle faille de sécurité découverte par une équipe de chercheurs. Voici ce que l’on sait sur cette nouvelle vulnérabilité (CVE-2026-3854).

CVE-2026-3854 : une faille dans GitHub

Une nouvelle faille de sécurité importante, associée à la référence CVE-2026-3854 et à un score CVSS de 8,7 sur 10, a été identifiée par les chercheurs en sécurité de Wiz. Ce problème se situe au niveau de , le proxy qui sert de point d’entrée pour les opérations Git. Ce composant intègre les options envoyées par l’utilisateur directement dans un en-tête interne (appelé ), mais sans nettoyer les points-virgules (), qui sont pourtant utilisés comme délimiteurs pour séparer les champs de sécurité.

Cette lacune permet à un utilisateur authentifié de forger sa requête de façon à injecter et à écraser des variables de configuration. L’équipe de chercheurs est ainsi parvenue à enchaîner plusieurs actions :

• Basculer hors de l’environnement sécurisé (sandbox) en altérant le paramètre .
• Rediriger le chemin d’exécution vers un emplacement où se situent des scripts personnalisés.
• Obtenir une exécution de code à distance directe sur les serveurs, avec les privilèges de l’utilisateur de service .

“Grâce à l’exécution de code hors sandbox en tant qu’utilisateur « git », nous disposions d’un contrôle total sur l’instance GHES, y compris l’accès en lecture/écriture au système de fichiers et la visibilité sur la configuration interne des services.”, précisent les chercheurs dans leur rapport.

Les chercheurs ont pu exploiter cette vulnérabilité directement sur GitHub.com (où il est facile d’avoir un accès authentifié), ce qui a offert un accès aux nœuds de stockage partagés. Des millions de dépôts publics et privés appartenant à diverses organisations étaient accessibles grâce à la prise de contrôle de l’utilisateur Git.

À ce sujet, voici les précisions apportées par les chercheurs et qui illustrent bien l’impact de cette vulnérabilité : “L’utilisateur git existe pour une raison : il gère toutes les opérations sur les dépôts au sein du nœud. De par sa conception, il dispose d’un accès étendu au système de fichiers pour chaque dépôt hébergé sur ce nœud. Compromettre cet utilisateur nous a permis de lire n’importe quel dépôt sur le nœud, quelle que soit l’organisation ou l’utilisateur qui en était propriétaire. Nous avons répertorié les entrées d’index des dépôts accessibles depuis deux nœuds compromis et avons trouvé des millions d’entrées sur chacun d’eux, appartenant à d’autres utilisateurs et organisations.”

Sur GitHub.com, cette vulnérabilité a été patchée dans les 6 heures qui ont suivi le rapport des équipes de Wiz. Le signalement de cette faille de sécurité remonte d’ailleurs au 6 mars 2026. Si vous utilisez cette plateforme SaaS pour héberger votre code, vous n’avez rien à faire. Mais une autre solution est également affectée par la CVE-2026-3854 : GitHub Enterprise Server.

88 % des instances GHES encore vulnérables

Même si tout est réglé du côté de GitHub.com, la situation est différente pour les entreprises hébergeant leurs propres serveurs via GitHub Enterprise Server. Dans le rapport de Wiz publié le 28 avril 2026, voici ce que l’on peut lire : “Les clients de GitHub Enterprise Server doivent effectuer la mise à jour sans tarder : au moment où nous écrivons ces lignes, nos données indiquent que 88 % des instances sont encore vulnérables.”

La version 3.19.1 et toutes les versions antérieures de GHES sont vulnérables à la CVE-2026-3854. Vous devez donc migrer vers l’une des versions qui intègrent le correctif de sécurité, à savoir à minima :

• 3.14.24
• 3.15.19
• 3.16.15
• 3.17.12
• 3.18.6
• 3.19.3

Il y a eu de nouvelles versions publiées depuis, puisque par exemple la version 3.14.24 date du 10 mars 2026, tandis que la version actuelle est la 3.14.26. Donc utilisez les références ci-dessus comme version minimale à utiliser sur votre instance GHES.