The IDE in the tab handed over a GitHub token in one click

On June 2, 2026, the security researcher Ammar Askar published a proof-of-concept for a zero-day in github.dev — the in-browser version of Visual Studio Code you reach by pressing . on any GitHub repository. A zero-day is a bug the vendor has had no time to fix because it became public the same moment it became known. In this case, by Askar's account, the public details went out roughly an hour after Microsoft was notified. He said he had moved to full public disclosure for VS Code findings out of frustration with how earlier reports to Microsoft's Security Response Center had been handled.

The mechanics are worth slowing down on, because they are a clean example of a category — not a one-off bug, but a shape of attack that browser-based development tools are going to keep producing.

A preview pane is not supposed to be a launchpad.

Code editors render a lot of untrusted content. A Markdown file you opened gets a rendered preview. A Jupyter notebook shows its output. These previews run inside a webview — a sandboxed mini-browser embedded in the editor, deliberately walled off from the editor's own privileges so that a malicious README cannot just take over your machine.

That wall is the whole point. Askar's exploit went over it.

The webview talks to the main editor through a message-passing channel — a narrow pipe the two sides use to coordinate. By abusing that channel, the malicious JavaScript running in the untrusted webview could simulate keystrokes — synthetic keydown events — in the main editor window. The keystrokes it chose were Ctrl+Shift+P, the shortcut that opens the Command Palette, the text box from which VS Code can run essentially any command it knows about.

From there the attack used a legitimate feature against itself. VS Code supports local workspace extensions: extensions placed in a project's .vscode/extensions folder, meant so a repository can ship its own tooling. Because a malicious repository controls its own files, it can ship its own extension — and the trust prompt that normally asks "do you really want to run this publisher's code?" was sidestepped by crafting custom keybindings in the extension's package.json. The publisher-trust dialog, the one human checkpoint in the chain, never appeared.

The prize was not the repo you opened.

The payload of this chain is a token. github.dev signs you in with GitHub and holds an OAuth token — a credential the browser presents to GitHub's servers to prove it is acting on your behalf. The point of OAuth is that the token can be scoped: an app should only get the narrow access it needs.

This token was not narrow. As Askar put it, the token is "not scoped to the particular repo you interacted with, meaning it has full access to every other repo that you have access to" — read and write, including private repositories. So the attacker did not get the public project you clicked into. They got a key to everything your account can reach: your private repos, your employer's private repos if you have access, the deploy keys and secrets sitting in those repos, the source you have never shown anyone. The proof-of-concept used it to enumerate the victim's private repositories — a list that, for most working developers, is itself sensitive.

This is the part that generalizes. Browser-based IDEs and cloud development environments are convenient precisely because they carry your credentials for you. github.dev holds a GitHub token. A cloud IDE holds a cloud token. An agentic coding assistant running in a browser tab holds whatever it needs to push code and call APIs. Each of those is a high-value secret sitting one sandbox-escape away from a web page you did not write.

The honest part: is it fixed?

Two reports, two different pictures, and the gap matters.

BleepingComputer, at the time of writing, described the issue as having no official patch and no CVE assigned, and offered a manual workaround: clear github.dev's cookies and local site data so the initial sign-in warning reappears.

The Hacker News carried statements from Microsoft engineers. Alexandru Dima, a Partner Software Engineering Manager, said "this issue does not affect VS Code Desktop" — the bug is specific to the browser-hosted github.dev, not the app you install on your machine. Microsoft later stated the vulnerability "has been mitigated for our services and no customer action is required," which points to a server-side change rather than a client patch you download.

We are not in a position to independently verify the mitigation, so we will not tell you the threat is over. What we can talk about is where the blast lands when a chain like this works — because that is an architecture question, and architecture is the part that does not depend on trusting a press statement.

Where the IDE actually runs.

Here is the thing about github.dev that makes it interesting to us: the entire editor is a web page. The webview, the Command Palette, the extension host, the OAuth token — all of it lives inside a browser tab. Which means the question "how much damage can this do" is, for once, the same question Bromure was built to answer about any tab.

In Bromure, every tab runs inside its own disposable virtual machine — a throwaway Linux guest on the Mac, with no path to your files, your keychain, or your other tabs. Run github.dev in a Bromure profile and the stolen OAuth token, the malicious webview, and the silently-installed local-workspace extension are all scoped to that one VM. Close the window on a non-persistent session and the world they lived in is wiped: the token cache, the cookies, the extension, the whole guest, gone.

Two things this geometry changes, and one it does not.

It changes what the token can reach. In a conventional browser, every GitHub session you have shares one cookie jar and one profile. A token lifted from your github.dev tab sits next to everything else that browser holds. In Bromure, you can run github.dev in its own profile — its own VM, its own cookies, its own storage — separated from your banking, your email, and your other GitHub identities. The compromise of the throwaway profile does not give the attacker the cookies in the others. They are not in the same machine.

It changes how long the foothold lasts. The most valuable move in this chain is the silently-installed extension — a foothold that persists every time you reopen the editor. Against a disposable session, there is nothing to come back to. The extension was installed into a VM that no longer exists.

What it does not solve.

It does not make the stolen token un-stolen. While the malicious session is live, the OAuth token is real and the attacker can use it to enumerate and read your private repositories in real time, from their own infrastructure. Isolation contains where the secret lives; it does not reach across the internet to GitHub's servers and revoke a credential the attacker already holds. The mitigations there are the ordinary ones: short-lived and tightly scoped tokens, revoking sessions after anything suspicious, and a vendor — Microsoft, here — closing the escape so the token is never reachable in the first place.

It is worth being precise about one comparison, because it is easy to slur. Bromure does not allow Chrome extensions to be installed at all — not sandboxed, not curated, not from any store. That is a deliberate product stance: the browser extension is one of the most-abused footholds on the modern web, so Bromure removes the category. But the extension in this story is a VS Code extension, installed by the github.dev web app into its own editor — a different thing from a Chrome extension, living inside the page rather than around it. Bromure's no-extensions rule does not reach inside github.dev to stop it. What Bromure does is contain the whole editor, token and extension and all, inside a VM that you can throw away.

Unless there is no token to steal.

There is a sharper way to use the same architecture, and it costs nothing: separate who you are from what you visit.

The whole chain exists to reach one secret — the OAuth token github.dev holds because you signed in. That token only needs to exist where you work on your own code. So give it exactly that much territory: a dedicated Bromure profile, signed in to GitHub, where you open your repositories and the repositories you already trust. The token lives there, and strangers' code does not.

Everything else — the interesting repo from a link, the proof-of-concept someone posted, the dependency you are evaluating — gets opened somewhere you are nobody: a profile that has never signed in to GitHub. Read the code on github.com as an anonymous visitor; if you reach for the editor, github.dev without a sign-in has nothing worth handing over. An unauthenticated session cannot leak a token it does not hold. The exploit chain runs, if it runs at all, inside a disposable VM with empty pockets.

That changes the shape of the defense. Containment limits the damage at step five, after the token is taken. Separation decapitates the chain at step one: the malicious repository never meets the credential. The discipline fits in one line — be signed in where you work, be nobody where you wander — and Bromure profiles make it a two-icon habit instead of a security policy.

The general lesson outlives this particular bug. As more of development moves into the browser — cloud IDEs, github.dev, agentic coding agents that run in a tab and carry push access — the credentials those tools hold become a standing target, one webview-escape away from a page you did not write. The defensible posture is not "trust the sandbox inside the IDE." It is to assume that sandbox will eventually leak, and to arrange things so that the page it leaks into is both disposable and broke.

Run the risky tab in its own world — a world where you are no one. When something gets in, there is nothing to take, and you close the world anyway.

That is what Bromure is for. Install it, give your own GitHub a profile of its own, visit everyone else's code as a stranger, and make the worst case a window you can close.