0-day VS Code github.dev : vol de tokens GitHub OAuth en 1 clic

Les faits

Le 3 juin 2026, le chercheur en sécurité Ammar Askar a divulgué publiquement une vulnérabilité 0-day affectant github.dev, la version navigateur de Visual Studio Code permettant d'éditer des dépôts GitHub directement depuis un navigateur web. La faille permet à un attaquant de voler le token OAuth GitHub d'une victime en lui faisant simplement cliquer sur un lien malveillant forgé. Aucun CVE n'a encore été attribué par MITRE, et GitHub n'a publié aucun correctif au moment de la divulgation. Askar indique avoir notifié GitHub une heure seulement avant la publication — délai volontairement réduit en raison d'une expérience antérieure négative avec le programme de réponse sécurité de Microsoft, qui avait refusé de traiter une vulnérabilité précédente jugée critique par le chercheur.

La vulnérabilité exploite le système de messagerie inter-webviews sandboxés dans l'architecture de VS Code navigateur. github.dev repose sur une architecture VS Code compilée pour le web (vscode-web), dans laquelle plusieurs contextes d'exécution isolés (webviews) communiquent entre eux via des messages de type postMessage. La faille réside dans une insuffisance de validation de l'origine des messages dans ce canal de communication interne, permettant à un contexte non autorisé d'envoyer des messages traités comme légitimes par la webview principale. Un attaquant peut abuser de ce mécanisme pour installer une extension VS Code malveillante à l'insu de l'utilisateur — extension capable d'extraire le token OAuth GitHub actif dans la session.

L'attaque se déroule en plusieurs étapes entièrement automatisées dès le clic initial. La victime clique sur un lien spécialement forgé pointant vers github.dev. Ce lien ouvre une page exploitant le canal de messagerie inter-webviews vulnérable. Le code malveillant injecte une fausse extension VS Code dans l'environnement navigateur, contournant les mécanismes d'isolement prévus par l'architecture sandboxée. Cette extension accède au token OAuth de la session GitHub active de l'utilisateur et le transmet immédiatement à un serveur contrôlé par l'attaquant. L'ensemble de l'exploitation s'exécute en moins d'une minute, sans aucune interaction supplémentaire de la victime au-delà du clic initial. La preuve de concept publiée par Askar sur GitHub démontre l'attaque en récupérant la liste complète des dépôts privés et publics accessibles avec le token volé.

L'impact d'un token GitHub OAuth compromis est considérable et s'étend bien au-delà de la simple lecture de code. Ce token offre typiquement l'accès à l'ensemble des dépôts privés et publics de la victime, aux secrets GitHub Actions (variables d'environnement CI/CD, credentials de déploiement cloud), aux webhooks configurés, aux déploiements automatisés, aux intégrations tierces (AWS CodePipeline, GCP Cloud Build, Azure DevOps, Slack) et aux packages GitHub Packages. Dans les environnements d'entreprise, cela peut signifier l'accès au code source propriétaire, aux pipelines CI/CD complets, aux configurations d'infrastructure as code (Terraform, Ansible, Kubernetes manifests) et aux secrets injectés dans les workflows GitHub Actions. Un acteur malveillant exploitant ce token peut agir avec l'ensemble des droits de la victime sur GitHub jusqu'à la révocation du token.

Les conséquences potentielles incluent l'injection de code malveillant dans des dépôts de manière furtive (attaque de chaîne d'approvisionnement logicielle), l'exfiltration de propriété intellectuelle et de code source, la modification de pipelines CI/CD pour déployer des backdoors en production, ou la désactivation des mécanismes de protection de branches et des workflows de revue de code. La technique de supply chain via des dépôts compromis est particulièrement redoutable car elle permet de toucher des milliers d'utilisateurs finaux via un seul point d'entrée compromis — la confiance des utilisateurs dans des packages publiés sur npm, PyPI ou Docker Hub étant généralement très élevée.

La gravité de cette divulgation dépasse la simple faille technique. GitHub est utilisé par plus de 100 millions de développeurs dans le monde et héberge le code source de millions d'entreprises, d'organisations gouvernementales et de projets open source critiques. github.dev est de plus en plus utilisé pour l'édition rapide en ligne, en particulier dans les contextes d'intégration avec GitHub Codespaces et GitHub Copilot. La surface d'attaque inclut tout développeur ayant utilisé github.dev récemment et susceptible de cliquer sur un lien partagé en apparence légitime via Slack, email professionnel, commentaires de Pull Request ou réseaux sociaux techniques comme LinkedIn ou Twitter.

La décision d'Ammar Askar de procéder à une divulgation immédiate sans respecter le délai de coordination standard de 90 jours met en lumière les tensions persistantes entre la communauté des chercheurs en sécurité et les grands éditeurs logiciels. Cette pratique, bien que controversée sur le plan éthique et légal dans certaines juridictions, crée une pression immédiate sur GitHub et Microsoft pour déployer rapidement un correctif. Les équipes de sécurité GitHub ont confirmé être au courant de la vulnérabilité et travailler activement à un patch, sans communiquer de délai précis.

Cette 0-day s'inscrit dans une tendance préoccupante d'attaques ciblant les environnements de développement et les IDE. En mai 2026, des dépôts internes de GitHub ont été compromis via une extension malveillante Nx Console pour VS Code, démontrant que la chaîne d'approvisionnement des outils de développement est devenue un vecteur d'attaque prioritaire. Les développeurs, souvent perçus comme des utilisateurs avertis, sont désormais la cible directe de vecteurs d'attaque sophistiqués exploitant leur confiance dans les outils qu'ils utilisent quotidiennement — et leur habitude de cliquer sur des liens de dépôts GitHub sans méfiance excessive.

Impact et exposition

Tout développeur ayant utilisé github.dev avec un compte GitHub est potentiellement exposé à cette 0-day. Il suffit qu'un attaquant lui fasse cliquer sur un lien malveillant — technique aisément réalisable via du spear phishing ciblé, des publications sur des forums techniques (Hacker News, Stack Overflow, Reddit), des commentaires dans des Issues ou Pull Requests GitHub, des messages Slack au sein d'organisations, ou des emails professionnels apparemment légitimes. Les cibles prioritaires incluent les mainteneurs de projets open source populaires (packages npm, PyPI, Docker Hub, Homebrew), les équipes DevSecOps ayant accès aux secrets CI/CD de production, et les développeurs dans des secteurs sensibles comme la défense, la finance ou la santé publique.

Une exploitation réussie donne accès au token OAuth actif de la victime, valide jusqu'à sa révocation manuelle ou son expiration naturelle. L'attaquant peut agir de manière totalement silencieuse pendant des heures ou des jours avant d'être détecté, les actions sur les API GitHub ne déclenchant pas d'alertes automatiques pour les utilisateurs individuels. Dans le contexte d'une attaque de chaîne d'approvisionnement, un seul développeur compromis ayant droits de merge sur un dépôt critique peut permettre l'injection de backdoors dans des logiciels distribués à des millions d'utilisateurs finaux.

L'absence de patch disponible au moment de la publication aggrave significativement le niveau de risque global. La seule mitigation technique proposée à ce jour consiste à effacer les cookies et données locales du domaine github.dev dans le navigateur, ce qui force une nouvelle authentification et invalide le contexte exploitable. Cette action ne protège cependant pas contre une future exploitation si l'utilisateur revient sur github.dev avant la publication d'un correctif officiel.

Recommandations immédiates

• Effacer immédiatement les cookies et données locales pour github.dev dans votre navigateur (Chrome : Paramètres > Confidentialité > Données de sites > github.dev > Supprimer)
• Révoquer et régénérer vos tokens GitHub OAuth : Settings GitHub > Developer Settings > Personal Access Tokens > Révoquer tous les tokens actifs
• Éviter d'utiliser github.dev jusqu'à la publication d'un correctif officiel par GitHub
• Activer l'authentification à deux facteurs (2FA) sur GitHub si ce n'est pas encore le cas — cela ne bloque pas l'exploitation mais limite l'impact d'une compromission de compte
• Sensibiliser les équipes de développement : ne pas cliquer sur des liens github.dev reçus de sources non vérifiées ou partagés sur des canaux publics
• Auditer les accès récents à vos dépôts via l'onglet Insights de GitHub pour détecter des accès depuis des IP ou user-agents inhabituels
• Pour les organisations : activer les politiques de restriction d'accès OAuth dans les paramètres GitHub Organization et envisager de bloquer github.dev pour les membres via des règles de proxy web