VS Code zero-day : vol de tokens GitHub OAuth en 1 clic — 3 700 repos compromis, patch Microsoft le 3 juin 2026

Le 2 juin 2026, le chercheur en sécurité Ammar Askar a publié les détails complets d'un zero-day dans Visual Studio Code qui permet à un attaquant de voler le token GitHub OAuth d'un développeur en un seul clic. L'exploit a été activement utilisé avant la divulgation, compromettant environ 3 700 dépôts internes GitHub. Microsoft a réagi en publiant un patch le 3 juin, soit 24 heures après la divulgation. Aucun CVE n'a été assigné à ce jour. Voici l'analyse technique complète et les actions concrètes pour les développeurs français.

Anatomie de l'attaque : du clic au vol de token

L'attaque exploite une faiblesse fondamentale dans l'architecture de VS Code : le système de webviews. Les webviews sont des cadres HTML intégrés à l'éditeur que les extensions utilisent pour afficher du contenu riche (prévisualisation Markdown, documentation, panneaux de configuration). Le problème est que ces webviews, même lorsqu'elles sont marquées comme « non fiables », ne sont pas correctement isolées du processus principal de VS Code.

La chaîne d'exploitation se déroule en cinq phases distinctes :

1. Phase 1 — Livraison : l'attaquant fournit un fichier ou un lien qui s'ouvre dans une webview VS Code. Cela peut être un fichier Markdown malveillant dans un dépôt, un lien de prévisualisation, ou tout contenu HTML rendu par une extension tierce. Un seul clic suffit.
2. Phase 2 — Simulation de frappes : le JavaScript malveillant exécuté dans la webview simule des frappes clavier. Il envoie la combinaison Ctrl+Shift+P pour ouvrir la Command Palette de VS Code. La faille clé est que VS Code ne distingue pas les frappes légitimes de l'utilisateur des frappes simulées par une webview.
3. Phase 3 — Installation d'extension : via la Command Palette, le script exécute la commande ext install <extension-malveillante> pour installer silencieusement une extension contrôlée par l'attaquant depuis le VS Code Marketplace. L'installation se fait sans confirmation utilisateur supplémentaire.
4. Phase 4 — Extraction du token : l'extension fraîchement installée accède au token GitHub OAuth stocké par VS Code. Ce token est celui que VS Code utilise pour l'intégration GitHub (connexion, push, pull, gestion des pull requests). Il est stocké dans le keychain du système mais accessible par toute extension VS Code via l'API authentication.getSession.
5. Phase 5 — Énumération et exfiltration : avec le token OAuth, l'extension énumère tous les dépôts privés accessibles et envoie la liste (ou le contenu) à un serveur de commande et contrôle (C2). Le scope du token détermine l'étendue de l'accès — souvent, il inclut repo, ce qui donne accès complet en lecture/écriture à tous les dépôts.

Le contexte : pourquoi Ammar Askar a choisi la full disclosure

Ammar Askar n'a pas suivi le processus classique de divulgation responsable (responsible disclosure) avec Microsoft. Il a opté pour la full disclosure — publication immédiate de tous les détails techniques, y compris la preuve de concept fonctionnelle. La raison : des expériences négatives répétées avec le Microsoft Security Response Center (MSRC).

Selon les déclarations d'Askar, le MSRC a un historique de délais excessifs sur les correctifs VS Code. Des vulnérabilités signalées de manière responsable par le passé ont mis des mois à être corrigées, parfois sans reconnaissance publique du chercheur. Le MSRC a également tendance à minimiser la sévérité des problèmes liés à VS Code en les considérant comme des problèmes « produit » plutôt que des vulnérabilités de sécurité.

Le résultat de la full disclosure est éloquent : Microsoft a publié le correctif en 24 heures. Quand le MSRC est confronté à une vulnérabilité publique activement exploitée, la machine s'accélère. Ce cas alimente le débat éthique récurrent dans la communauté sécurité : la divulgation responsable fonctionne-t-elle quand l'éditeur ne joue pas le jeu ?

Impact confirmé : 3 700 dépôts internes GitHub compromis

L'exploitation active de cette vulnérabilité a permis l'accès à environ 3 700 dépôts internes GitHub. Le mécanisme est direct : une fois le token GitHub OAuth récupéré, l'attaquant utilise l'API GitHub pour énumérer tous les dépôts accessibles avec les permissions du token. Le scope repo (le plus courant pour l'intégration VS Code ↔ GitHub) donne accès en lecture et écriture à tous les dépôts privés de l'utilisateur et des organisations dont il est membre.

Ce chiffre de 3 700 est particulièrement significatif. Il ne s'agit pas de 3 700 dépôts d'un seul utilisateur : cela suggère que plusieurs développeurs ont été compromis, chacun avec des accès à différentes organisations et dépôts. L'attaque a été particulièrement efficace car les tokens OAuth GitHub volés via VS Code ont généralement des scopes larges — les développeurs ne restreignent que rarement les permissions de leur intégration GitHub dans VS Code.

Les risques spécifiques pour les organisations françaises :

• Propriété intellectuelle : accès au code source propriétaire, aux algorithmes, aux secrets métier.
• Secrets en dur : clés API, credentials de bases de données, tokens de services tiers stockés dans les dépôts (malgré les bonnes pratiques, c'est encore extrêmement courant).
• Supply chain : si l'attaquant obtient un accès en écriture, il peut injecter du code malveillant directement dans les dépôts, créant une chaîne d'attaque en cascade.
• Conformité RGPD/NIS2 : l'exfiltration de données de code contenant des traitements de données personnelles constitue une violation nécessitant notification à la CNIL sous 72 heures.

Analyse technique : pourquoi VS Code était vulnérable

Le problème de fond est architectural. VS Code est construit sur Electron, qui utilise Chromium comme moteur de rendu. Les webviews sont des iframes Chromium qui exécutent du HTML/CSS/JS arbitraire. En théorie, les webviews devraient être isolées du processus principal de VS Code via le Content Security Policy (CSP) et le sandboxing Chromium. En pratique, l'isolation était incomplète sur un point critique : les événements clavier.

Dans le modèle Electron de VS Code, les événements clavier générés par une webview pouvaient remonter (bubbling) jusqu'au processus principal de l'éditeur. Cela signifie qu'un KeyboardEvent créé par du JavaScript dans une webview était traité de la même manière qu'une frappe physique de l'utilisateur. Ce défaut permettait à la webview de :

• Ouvrir la Command Palette (Ctrl+Shift+P)
• Taper du texte dans le champ de recherche de la palette
• Sélectionner et exécuter n'importe quelle commande VS Code
• Y compris Extensions: Install Extension suivi du nom d'une extension

Une fois l'extension installée, elle bénéficie des privilèges complets de l'API VS Code — y compris l'accès à vscode.authentication.getSession('github') qui retourne directement le token OAuth GitHub stocké dans le keychain système. Aucune confirmation utilisateur n'est demandée pour cette opération.

Le patch Microsoft : ce qu'il corrige et ce qu'il ne corrige pas

Le correctif publié le 3 juin 2026 (VS Code version 1.102.1 et supérieures) apporte deux modifications clés :

1. Isolation des événements clavier : les KeyboardEvent générés dans une webview non fiable ne remontent plus au processus principal de VS Code. Les frappes clavier simulées restent confinées à la webview.
2. Blocage de l'installation d'extension via webview : la commande ext install ne peut plus être déclenchée depuis un contexte de webview marqué comme non fiable.

Ce que le patch ne corrige pas :

• Les tokens GitHub OAuth déjà volés avant le 3 juin restent valides jusqu'à révocation explicite.
• Les extensions déjà installées (légitimes ou non) ont toujours un accès complet aux tokens OAuth via l'API authentication.getSession.
• Le modèle de permissions de VS Code reste fondamentalement le même : pas de sandboxing par extension, pas de permissions granulaires.

Ce que ça signifie pour vous

Si vous êtes développeur en France et que vous utilisez VS Code avec l'intégration GitHub, voici les actions immédiates à prendre, classées par priorité.

Priorité 1 — Mise à jour immédiate (5 minutes)

Mettez à jour VS Code vers la version 1.102.1 ou supérieure. Vérifiez votre version actuelle via Help > About ou code --version en terminal. Si vous ne pouvez pas mettre à jour immédiatement, désactivez toutes les extensions non essentielles et évitez d'ouvrir des fichiers de sources non fiables dans VS Code.

Priorité 2 — Révocation du token GitHub OAuth (15 minutes)

Si vous avez ouvert des fichiers de sources non fiables (repos publics, fichiers téléchargés, liens reçus par email) dans VS Code avant le 3 juin 2026, considérez votre token GitHub OAuth comme potentiellement compromis. Allez dans GitHub > Settings > Applications > Authorized OAuth Apps, trouvez l'entrée VS Code et révoquez le token. Reconnectez-vous ensuite depuis VS Code pour générer un nouveau token.

Priorité 3 — Audit des dépôts privés (1 heure)

Si le token a été compromis, auditez l'activité récente sur vos dépôts privés. Vérifiez les logs d'audit GitHub (Settings > Audit log pour les organisations, Security > Activity > Sessions pour le compte personnel) pour détecter des accès ou des clones inhabituels. Recherchez spécifiquement les accès via l'API entre le 2 et le 3 juin.

Priorité 4 — Rotation des secrets dans les repos (variable)

Si un attaquant a eu accès à vos dépôts privés, il a potentiellement accédé à tous les secrets stockés dans le code : clés API, fichiers .env committés par erreur, credentials dans les fichiers de configuration, tokens de services tiers. Identifiez et effectuez la rotation de chaque secret concerné.

Le problème systémique : les éditeurs de code ne sont pas des navigateurs

Cet incident s'inscrit dans une tendance plus large. En mai 2026, nous avions documenté la compromission de l'extension Nx Console par le groupe TeamPCP qui avait permis l'accès aux systèmes internes de GitHub. Plus tôt dans l'année, notre article sur les extensions Glassworm détaillait comment des extensions dormantes pouvaient être activées à distance pour exfiltrer des données.

Le point commun de toutes ces attaques : le modèle de confiance des extensions VS Code est fondamentalement défaillant. Contrairement aux navigateurs web qui ont passé 15 ans à développer des modèles de sandboxing robustes (processus isolés par onglet, permissions granulaires, CSP stricte), VS Code traite chaque extension comme un composant fiable avec un accès complet au système.

Les raisons sont historiques et économiques :

• Performance : le sandboxing par extension ajouterait une latence significative. Les développeurs sont extrêmement sensibles à la réactivité de leur éditeur.
• Écosystème : VS Code doit sa domination à son écosystème d'extensions. Ajouter des restrictions strictes pourrait fragmenter cet écosystème et pousser les développeurs vers d'autres outils.
• Compatibilité : de nombreuses extensions légitimes dépendent d'un accès large au système (linters, formatters, débogueurs, terminaux intégrés).

Pour les équipes françaises, le message est clair : l'éditeur de code est désormais un vecteur d'attaque de premier ordre. Il doit être traité avec le même niveau de vigilance qu'un navigateur web ou un client email. La sécurisation de l'environnement de développement local n'est plus un luxe — c'est une nécessité opérationnelle.

Implications légales pour les entreprises françaises

Au-delà de l'aspect technique, cette vulnérabilité a des implications réglementaires directes pour les entreprises françaises :

• RGPD (article 33) : si des données personnelles étaient présentes dans les dépôts compromis (bases de données de test, fichiers de configuration avec des emails, données de staging), une notification à la CNIL dans les 72 heures est obligatoire.
• NIS2 : les entités essentielles et importantes doivent notifier les incidents de sécurité à l'ANSSI. Un vol de tokens GitHub avec accès à des dépôts d'infrastructure critique entre potentiellement dans le périmètre.
• DORA : pour les entreprises du secteur financier, l'utilisation d'un éditeur de code compromis touchant des dépôts de systèmes d'information critiques doit être signalée dans le cadre de la réglementation DORA.

Pour les équipes basées à Paris, Lyon, Nantes ou Bordeaux qui développent des logiciels traitant des données sensibles, la question n'est pas de savoir si un audit est nécessaire — c'est de déterminer l'urgence de la rémédiation.

Leçons pour l'écosystème open source français

Cette attaque met en lumière plusieurs failles structurelles dans l'écosystème de développement open source qui concernent directement la communauté française :

1. La confiance implicite dans les outils : VS Code est l'éditeur de code le plus utilisé au monde (73% de part de marché parmi les développeurs). Cette domination crée une confiance implicite qui est exploitée par les attaquants. Les développeurs français doivent apprendre à considérer leur éditeur comme un logiciel potentiellement vulnérable, pas comme une plateforme sûre par défaut.
2. La dépendance aux intégrations OAuth : l'intégration transparente entre VS Code et GitHub est un gain de productivité considérable. Mais elle crée un point unique de défaillance : un seul token compromise donne accès à tout. La solution est de restreindre les scopes OAuth au strict nécessaire et de privilégier les tokens à durée de vie courte.
3. Le débat full disclosure vs. responsible disclosure : la communauté sécurité française (ANSSI, CERT-FR, chercheurs indépendants) privilégie traditionnellement la divulgation responsable. Le cas Askar montre que cette approche a ses limites quand l'éditeur ne joue pas le jeu. Un équilibre plus nuancé est nécessaire.

Pour approfondir les enjeux de la supply chain open source, consultez notre article récent sur le blog d'Ammar Askar pour les détails techniques complets de la vulnérabilité, et notre propre analyse des audits d'extensions VS Code pour les mesures préventives durables.

Conclusion : Le zero-day VS Code découvert par Ammar Askar est un cas d'école de vulnérabilité dans la chaîne d'outils de développement. Un clic, une webview malveillante, et l'attaquant accède à tous vos dépôts GitHub privés. Le patch est disponible — appliquez-le aujourd'hui. Mais le patch seul ne suffit pas : révoquez vos tokens OAuth GitHub, auditez vos dépôts et mettez en place une politique de sécurité durable pour vos extensions. L'éditeur de code est désormais un vecteur d'attaque majeur — traitez-le comme tel. Obtenir un devis gratuit si vous avez besoin d'un accompagnement sur l'audit de votre environnement de développement.