Ouvrez un dépôt dans github.dev, cliquez sur un lien, et un éditeur qui tourne dans un onglet de navigateur a installé silencieusement une extension, lu votre token OAuth GitHub et commencé à lister vos dépôts privés. Aucun téléchargement. Aucun bouton « Autoriser ». L'IDE tout entier vit dans une page web — ce qui est précisément pourquoi le rayon d'explosion est une question qui concerne le navigateur, pas l'IDE.

Le 2 juin 2026, le chercheur en sécurité Ammar Askar a publié une preuve de concept pour un zero-day dans github.dev — la version dans le navigateur de Visual Studio Code que vous atteignez en pressant . sur n'importe quel dépôt GitHub. Un zero-day est un bug que l'éditeur n'a eu aucun délai pour corriger parce qu'il est devenu public au moment même où il est devenu connu. Dans ce cas, selon le récit d'Askar, les détails publics sont sortis environ une heure après que Microsoft a été notifié. Il a dit être passé à la divulgation publique complète pour ses découvertes sur VS Code par frustration face à la manière dont ses signalements antérieurs au Security Response Center de Microsoft avaient été traités.

La mécanique vaut la peine qu'on ralentisse, parce qu'elle est un exemple net d'une catégorie — non pas un bug isolé, mais une forme d'attaque que les outils de développement basés sur le navigateur vont continuer de produire.

Un volet d'aperçu n'est pas censé être une rampe de lancement.

Les éditeurs de code rendent beaucoup de contenu non fiable. Un fichier Markdown que vous avez ouvert reçoit un aperçu rendu. Un notebook Jupyter affiche sa sortie. Ces aperçus tournent à l'intérieur d'une webview — un mini-navigateur en bac à sable embarqué dans l'éditeur, délibérément muré loin des privilèges de l'éditeur lui-même, afin qu'un README malveillant ne puisse pas simplement prendre le contrôle de votre machine.

Ce mur est toute la raison d'être. L'exploit d'Askar est passé par-dessus.

La webview parle à l'éditeur principal via un canal de passage de messages (message-passing channel) — un tuyau étroit que les deux côtés utilisent pour se coordonner. En abusant de ce canal, le JavaScript malveillant tournant dans la webview non fiable pouvait simuler des frappes clavier — des événements keydown synthétiques — dans la fenêtre principale de l'éditeur. Les frappes qu'il a choisies étaient Ctrl+Shift+P, le raccourci qui ouvre la Command Palette, le champ de texte depuis lequel VS Code peut exécuter essentiellement n'importe quelle commande qu'il connaît.

À partir de là, l'attaque a retourné une fonctionnalité légitime contre elle-même. VS Code prend en charge les extensions de l'espace de travail local (local workspace extensions) : des extensions placées dans le dossier .vscode/extensions d'un projet, conçues pour qu'un dépôt puisse livrer son propre outillage. Comme un dépôt malveillant contrôle ses propres fichiers, il peut livrer sa propre extension — et l'invite de confiance qui demande normalement « voulez-vous vraiment exécuter le code de cet éditeur ? » a été contournée en fabriquant des raccourcis personnalisés dans le package.json de l'extension. La boîte de dialogue de confiance de l'éditeur, le seul point de contrôle humain de la chaîne, n'est jamais apparue.

La chaîne en un clic de github.dev. Un volet d'aperçu (une webview en bac à sable) pilote l'éditeur dans lequel il vit : il simule une frappe Ctrl+Shift+P, ouvre la Command Palette et déclenche une extension de l'espace de travail local dont les raccourcis sautent l'invite de confiance de l'éditeur. L'extension lit ensuite le token OAuth GitHub que la page détenait.

Le butin n'était pas le dépôt que vous avez ouvert.

La charge utile de cette chaîne est un token. github.dev vous connecte avec GitHub et détient un token OAuth — un credential que le navigateur présente aux serveurs de GitHub pour prouver qu'il agit en votre nom. Tout l'intérêt d'OAuth est que le token peut être scopé : une application ne devrait obtenir que l'accès étroit dont elle a besoin.

Ce token n'était pas étroit. Comme Askar l'a formulé, le token « n'est pas scopé au dépôt particulier avec lequel vous avez interagi, ce qui signifie qu'il a un accès complet à tous les autres dépôts auxquels vous avez accès » — en lecture et en écriture, y compris les dépôts privés. Donc l'attaquant n'a pas obtenu le projet public dans lequel vous avez cliqué. Il a obtenu une clé vers tout ce que votre compte peut atteindre : vos dépôts privés, les dépôts privés de votre employeur si vous y avez accès, les deploy keys et les secrets posés dans ces dépôts, le code source que vous n'avez jamais montré à personne. La preuve de concept l'a utilisé pour énumérer les dépôts privés de la victime — une liste qui, pour la plupart des développeurs en activité, est elle-même sensible.

C'est la partie qui se généralise. Les IDE basés sur le navigateur et les environnements de développement dans le cloud sont commodes précisément parce qu'ils transportent vos credentials pour vous. github.dev détient un token GitHub. Un IDE cloud détient un token cloud. Un assistant de codage agentique tournant dans un onglet de navigateur détient tout ce dont il a besoin pour pousser du code et appeler des API. Chacun de ceux-là est un secret de grande valeur posé à une évasion de bac à sable d'une page web que vous n'avez pas écrite.

La partie honnête : est-ce corrigé ?

Deux rapports, deux tableaux différents, et l'écart compte.

BleepingComputer, au moment de la rédaction, a décrit le problème comme n'ayant aucun correctif officiel et aucun CVE assigné, et a proposé un contournement manuel : effacer les cookies et les données de site locales de github.dev pour que l'avertissement de connexion initial réapparaisse.

The Hacker News a relayé des déclarations d'ingénieurs Microsoft. Alexandru Dima, Partner Software Engineering Manager, a dit que « ce problème n'affecte pas VS Code Desktop » — le bug est spécifique au github.dev hébergé dans le navigateur, pas à l'application que vous installez sur votre machine. Microsoft a ensuite déclaré que la vulnérabilité « a été atténuée pour nos services et qu'aucune action client n'est requise », ce qui pointe vers un changement côté serveur plutôt qu'un correctif client que vous téléchargez.

Nous ne sommes pas en mesure de vérifier l'atténuation de manière indépendante, donc nous ne vous dirons pas que la menace est terminée. Ce dont nous pouvons parler, c'est de l'endroit où la déflagration retombe quand une chaîne comme celle-ci fonctionne — parce que c'est une question d'architecture, et l'architecture est la partie qui ne dépend pas de la confiance accordée à un communiqué de presse.

Là où l'IDE tourne réellement.

Voici ce qui rend github.dev intéressant pour nous : l'éditeur tout entier est une page web. La webview, la Command Palette, l'hôte d'extensions, le token OAuth — tout cela vit à l'intérieur d'un onglet de navigateur. Ce qui signifie que la question « combien de dégâts cela peut-il faire » est, pour une fois, la même question que Bromure a été conçu pour répondre au sujet de n'importe quel onglet.

Dans Bromure, chaque onglet tourne à l'intérieur de sa propre machine virtuelle jetable — un invité Linux éphémère sur le Mac, sans aucun chemin vers vos fichiers, votre trousseau ou vos autres onglets. Faites tourner github.dev dans un profil Bromure et le token OAuth volé, la webview malveillante et l'extension de l'espace de travail local installée silencieusement sont tous scopés à cette unique VM. Fermez la fenêtre sur une session non persistante et le monde dans lequel ils vivaient est effacé : le cache de tokens, les cookies, l'extension, l'invité tout entier, partis.

Le même exploit github.dev, deux navigateurs. À gauche, un navigateur conventionnel : l'onglet partage un pot de cookies et un profil avec chaque autre session GitHub que vous avez, et le token volé est de longue durée. À droite, Bromure : l'onglet est une VM jetable. Le token, la webview et l'extension implantée sont scopés à un profil qui est jeté quand vous le fermez. Et la version la plus tranchante n'est pas représentée — ouvrez les dépôts d'inconnus dans un profil qui ne s'est jamais connecté, et il n'y a aucun token à voler du tout.

Deux choses que cette géométrie change, et une qu'elle ne change pas.

Elle change ce que le token peut atteindre. Dans un navigateur conventionnel, chaque session GitHub que vous avez partage un seul pot de cookies et un seul profil. Un token soutiré de votre onglet github.dev se trouve à côté de tout le reste que ce navigateur détient. Dans Bromure, vous pouvez faire tourner github.dev dans son propre profil — sa propre VM, ses propres cookies, son propre stockage — séparé de votre banque, de votre e-mail et de vos autres identités GitHub. La compromission du profil jetable ne donne pas à l'attaquant les cookies des autres. Ils ne sont pas dans la même machine.

Elle change combien de temps dure le point d'ancrage. Le coup le plus précieux de cette chaîne est l'extension installée silencieusement — un point d'ancrage qui persiste à chaque fois que vous rouvrez l'éditeur. Contre une session jetable, il n'y a rien vers quoi revenir. L'extension a été installée dans une VM qui n'existe plus.

Ce qu'elle ne résout pas.

Elle ne rend pas le token volé non volé. Tant que la session malveillante est active, le token OAuth est réel et l'attaquant peut l'utiliser pour énumérer et lire vos dépôts privés en temps réel, depuis sa propre infrastructure. L'isolation contient l'endroit où le secret vit ; elle ne s'étend pas à travers l'internet jusqu'aux serveurs de GitHub pour révoquer un credential que l'attaquant détient déjà. Les atténuations là-dessus sont les ordinaires : des tokens à courte durée et étroitement scopés, la révocation des sessions après tout événement suspect, et un éditeur — Microsoft, ici — qui ferme l'évasion afin que le token ne soit jamais atteignable au départ.

Il vaut la peine d'être précis sur une comparaison, parce qu'elle est facile à brouiller. Bromure n'autorise pas du tout l'installation d'extensions Chrome — ni en bac à sable, ni sélectionnées, ni depuis aucun store. C'est une posture produit délibérée : l'extension de navigateur est l'un des points d'ancrage les plus abusés du web moderne, donc Bromure supprime la catégorie. Mais l'extension dans cette histoire est une extension VS Code, installée par l'application web github.dev dans son propre éditeur — une chose différente d'une extension Chrome, vivant à l'intérieur de la page plutôt qu'autour d'elle. La règle « pas d'extensions » de Bromure ne va pas à l'intérieur de github.dev pour l'arrêter. Ce que fait Bromure, c'est contenir l'éditeur tout entier, token et extension compris, à l'intérieur d'une VM que vous pouvez jeter.

À moins qu'il n'y ait aucun token à voler.

Il y a une manière plus tranchante d'utiliser la même architecture, et elle ne coûte rien : séparer qui vous êtes de ce que vous visitez.

La chaîne tout entière existe pour atteindre un seul secret — le token OAuth que github.dev détient parce que vous vous êtes connecté. Ce token n'a besoin d'exister que là où vous travaillez sur votre propre code. Alors donnez-lui exactement ce territoire-là : un profil Bromure dédié, connecté à GitHub, où vous ouvrez vos dépôts et les dépôts auxquels vous faites déjà confiance. Le token y vit, et le code d'inconnus n'y entre pas.

Tout le reste — le dépôt intéressant venu d'un lien, la preuve de concept que quelqu'un a postée, la dépendance que vous évaluez — s'ouvre quelque part où vous n'êtes personne : un profil qui ne s'est jamais connecté à GitHub. Lisez le code sur github.com en visiteur anonyme ; si vous tendez la main vers l'éditeur, github.dev sans connexion n'a rien qui vaille la peine d'être remis. Une session non authentifiée ne peut pas fuiter un token qu'elle ne détient pas. La chaîne d'exploit tourne, si tant est qu'elle tourne, à l'intérieur d'une VM jetable aux poches vides.

Cela change la forme de la défense. Le confinement limite les dégâts à l'étape cinq, après que le token est pris. La séparation décapite la chaîne à l'étape un : le dépôt malveillant ne rencontre jamais le credential. La discipline tient en une ligne — connecté là où vous travaillez, personne là où vous errez — et les profils Bromure en font une habitude à deux icônes plutôt qu'une politique de sécurité.

La leçon générale survit à ce bug particulier. À mesure que le développement migre vers le navigateur — IDE cloud, github.dev, agents de codage agentiques qui tournent dans un onglet et transportent un accès en écriture — les credentials que ces outils détiennent deviennent une cible permanente, à une évasion de webview d'une page que vous n'avez pas écrite. La posture défendable n'est pas « faites confiance au bac à sable à l'intérieur de l'IDE ». C'est de supposer que ce bac à sable finira par fuiter, et d'arranger les choses de sorte que la page dans laquelle il fuit soit à la fois jetable et sans le sou.

Faites tourner l'onglet risqué dans son propre monde — un monde où vous n'êtes personne. Quand quelque chose entre, il n'y a rien à prendre, et vous fermez le monde de toute façon.

C'est à cela que sert Bromure. Installez-le, donnez à votre propre GitHub un profil à lui, visitez le code de tous les autres en inconnu, et faites du pire cas une fenêtre que vous pouvez fermer.