VAPT | SecureRoot Editorial Team | 4 June 2026 | 8 min read

VAPT | SecureRoot Editorial Team | 4 June 2026 | 8 min read

On 2 June 2026, a security researcher published working exploit code for a flaw in Visual Studio Code that needs nothing more than a single click to steal your GitHub token. Once that token is gone, an attacker can read, change, and push code to every private repository you can reach. There is no official patch yet, and the whole attack runs in under a minute. If your developers use github.dev or open repositories they did not write, this is worth ten minutes of your attention today. Here is what happened, who is at risk, and the practical steps to take right now.

What exactly is this VS Code zero day?

A zero day is a flaw that is publicly known or being attacked before the vendor has a fix. This one sits inside the webview system that VS Code and github.dev use to display content safely inside the editor.

The researcher, Ammar Askar, showed that the design which is meant to keep untrusted content sandboxed can be turned against the user. By abusing the way messages pass between a webview and the main editor, malicious code can simulate keystrokes, install an extension without a prompt, and then grab the GitHub OAuth token that github.dev hands to the session. The full technical writeup was covered in detail by BleepingComputer.

The detail that makes this serious is scope. The stolen token is not limited to the one repository you were looking at. It carries the same access you have across your whole account.

How the attack actually works

The exploit chain is short, and that is the worrying part. Here is the sequence in plain terms.

1. The bait. You click a crafted link, or you open a repository that an attacker controls inside github.dev, the browser based version of VS Code.
2. Fake keystrokes. Hidden JavaScript runs inside a sandboxed webview and simulates key presses in the main editor.
3. Silent install. Those keystrokes accept a notification and install a malicious extension. There is no publisher trust dialog because the extension is dropped straight into the extensions folder rather than the Marketplace.
4. Token grabbed. The extension reads the GitHub OAuth token that github.dev receives, then uses it to query the GitHub API and enumerate everything you can access.

There is no CSRF protection on github.dev, which means any ordinary link on the internet can redirect a victim straight into step one. On the desktop version of VS Code, the same chain can escalate further, because extensions have full access to Node.js APIs, which opens the door to remote code execution on the machine itself.

Why this is more than a developer problem

It is tempting to file this under "an IT issue for the engineering team." That would be a mistake. A stolen GitHub token is a business risk, not just a technical one.

Think about what lives in your private repositories. Source code, of course, but also API keys, database credentials, cloud secrets, customer data in test fixtures, and the deployment pipelines that push code to production. An attacker with your token can quietly read all of it. Worse, they can push changes, which means a supply chain backdoor planted in your own codebase that ships to your customers under your name.

For regulated businesses in India, the stakes climb higher. A breach that exposes personal data triggers obligations under the DPDP Act, and incidents must be reported to CERT-In within the prescribed timelines. The cost of a quiet token theft is rarely just the token.

Who is exposed right now

You should treat this as relevant if any of the following are true for your team.

• You or your developers use github.dev. This is the editor you reach by pressing the period key on any GitHub repository in the browser. It is convenient, which is exactly why it is widely used.
• You open repositories you did not create. Cloning and opening an attacker's repository in desktop VS Code can trigger the desktop variant of the attack.
• You click links during the working day. Because github.dev has no CSRF protection, a normal developer doing normal work is the target. No special access or insider mistake is needed.

This is the uncomfortable truth about modern development tooling. The editor is no longer a passive text box. It runs code, holds tokens, and talks to the network, which makes it part of your attack surface. We cover this thinking in our work on attack surface management.

For organisations, add two more steps. First, send a short internal note to every developer with the actions above, because awareness here is faster than any tool. Second, check your monitoring for unusual GitHub API activity, which is where a managed SOC service earns its keep by spotting the enumeration step before it turns into exfiltration.

How a security partner helps beyond the quick fixes

Patching one flaw is housekeeping. Building a development process that survives the next one is the real goal. This is where structured testing and review matter.

Regular VAPT finds the gaps an attacker would use, before they do, across your web apps, APIs, and networks. A secure code review catches the hardcoded secrets and weak token handling that turn a stolen credential into a full breach. And folding security into your pipeline through DevSecOps means token scope, extension policy, and dependency checks become part of how you ship, not an afterthought.

If you are building a longer term programme, our ISO 27001 consulting and broader GRC services help you put repeatable controls around developer access and incident response. For teams without a full time security lead, a vCISO can own these decisions and report them to your board.

Frequently asked questions:

Is the VS Code zero day patched yet?

At the time of writing there is no official patch and no assigned CVE. Treat the mitigation steps above as your protection until GitHub or Microsoft confirms a fix. Verify current status before assuming you are safe.

Does this affect the desktop version of VS Code or only github.dev?

Both. The browser based github.dev is the easier target because a single link can trigger it. The desktop version can also be exploited if a victim clones and opens an attacker's repository, and on desktop the impact can reach remote code execution.

What can an attacker do with a stolen GitHub OAuth token?

The token carries the same access you have. That means reading every private repository you can reach, modifying and pushing code, and potentially planting a supply chain backdoor. It is not limited to the single repository you were viewing.

How do I know if my token was already stolen?

Look for GitHub API activity you did not initiate, unexpected new extensions on github.dev, and any sign in events from unfamiliar locations. If anything looks off, revoke and reissue your tokens immediately, then review repository access logs.

How can we stop this kind of attack in future?

Limit token scope where GitHub allows it, control which extensions developers can install, monitor for unusual API activity, and test your environment regularly. A combination of VAPT, secure code review, and continuous monitoring closes most of the path an attacker would take.

The takeaway

A single click should never be enough to hand over your entire codebase, yet here we are. The lesson is not to fear your editor, but to treat your development environment as part of your threat model, because attackers already do. Clear your github.dev data, warn your team, and rotate anything that looks risky today.

If you want a second pair of eyes on where your developer tooling and code could be exposed, book a free 30 minute scoping call with our senior consultants. We will walk through your environment and show you where the gaps are, whether you work with us or not.