You already have an account? Log In

When Your IDE Becomes the Attacker: Lessons from the VS Code GitHub Token Flaw

Posted on 03.06.2026

For most developers, Visual Studio Code is the most trusted piece of software on the laptop. It edits the code, runs the terminal, signs commits, talks to GitHub, manages secrets, and quietly holds the keys to everything from a hobby repo to a production deployment pipeline. That trust is precisely what makes it dangerous.

The recent disclosure of a one-click vulnerability that let attackers siphon full GitHub OAuth tokens from VS Code users is a useful reminder that the tools we write code with are now part of our attack surface — and arguably the highest-value part. For Australian developers, contractors and small dev shops who often run lean on security tooling, it's worth pausing to understand what went wrong, why this class of bug keeps appearing, and what a sensible defensive posture actually looks like.

What actually happened

According to reporting from BleepingComputer, The Hacker News, CyberSecurityNews and gbhackers, researchers found a zero-day in VS Code that allowed attackers to steal a user's GitHub OAuth token with a single click. The flaw sat in the integration between VS Code and GitHub's authentication flow — the same flow that lets you sign in once and then pull, push, open pull requests and use Copilot without thinking about it again.

The exploit didn't require a malicious extension or a compromised repo full of dodgy code. A crafted link, opened in the wrong context, was enough to hand an attacker the OAuth token associated with the victim's GitHub account. With that token, an attacker can do roughly anything the user can do on GitHub: read private repositories, push commits, modify workflows, exfiltrate secrets stored in repos, and in many cases pivot into the organisations that user belongs to.

This wasn't an obscure edge case. It was a single-click, low-friction path from "clicked a link" to "complete account takeover for everything tied to that token."

Why developer tools are uniquely risky

The VS Code flaw is a specific bug, but the pattern is the broader story. Modern developer tooling has three properties that make it a magnet for attackers:

It holds high-value secrets. Editors, terminals and CLIs cache OAuth tokens, SSH keys, cloud credentials, package registry tokens and AI assistant API keys. A single stolen GitHub token can be worth more than a stolen credit card.
It executes arbitrary code by design. An IDE's job is to run things — build scripts, language servers, debuggers, extensions, devcontainers. The line between "opening a project" and "executing untrusted code" is much thinner than most developers admit.
It's deeply integrated with the browser and the OS. Custom URL handlers (like vscode://), webviews, embedded auth flows and extension marketplaces all create paths where a single click in a browser can trigger behaviour inside the editor — which is exactly the seam this GitHub token bug lived in.

Put together, this means a developer's workstation is effectively a privileged jump host into production. Attackers have noticed. Supply chain attacks against npm and PyPI, malicious VS Code extensions, poisoned GitHub Actions, and now one-click OAuth theft are all variations on the same theme: don't attack the server, attack the person who deploys to it.

What a stolen GitHub token actually buys an attacker

It's worth being concrete about the blast radius, because "OAuth token theft" sounds abstract. A full GitHub token tied to a developer account typically allows:

Cloning every private repository the user can read, including ones owned by their employer or clients.
Pushing commits as that user — which means injecting backdoors that appear in the Git history under a trusted name, often with a verified signature.
Modifying GitHub Actions workflows, which run with their own secrets and can be used to exfiltrate AWS, Azure or GCP credentials.
Reading and writing to package registries linked via GitHub identity, enabling supply chain attacks downstream.
Accessing GitHub Copilot and other paid services billed to the victim or their org.

For an Australian agency that builds software for clients under NDA, or a fintech that stores infrastructure-as-code in GitHub, the practical consequence of one developer clicking the wrong link can be a notifiable data breach under the Privacy Act. The token is small. The fallout isn't.

Practical defences that actually move the needle

You can't patch human curiosity, and you can't audit every line of every extension you've installed. But you can dramatically reduce the value of a stolen token and the likelihood that one click ruins your week.

1. Keep VS Code and its extensions updated — aggressively

The fix for this specific bug ships in a VS Code update. Turn on auto-updates for the editor itself, and review your extensions list at least quarterly. Uninstall anything you haven't used in six months. Every extension is code running inside your IDE with access to your workspace.

2. Treat OAuth tokens as short-lived, not lifetime

Go to GitHub's Applications settings regularly and revoke tokens you don't recognise or no longer need. If you've ever clicked a suspicious link, revoke everything and re-authenticate — it's a five-minute job that invalidates a stolen token instantly.

3. Use fine-grained personal access tokens and SSO

Where possible, prefer GitHub's fine-grained PATs over classic tokens — they let you scope access to specific repositories and permissions. If your organisation uses GitHub Enterprise, enforce SAML SSO so tokens have to be re-authorised periodically.

4. Turn on 2FA and use passkeys

2FA won't stop OAuth token theft (the token already represents an authenticated session), but it raises the cost of every other path an attacker might try once they're inside. Passkeys, now supported by GitHub, remove phishable credentials entirely.

5. Be deliberate about what you click from inside the editor

Webview-based exploits and custom URL handlers exist because developers click links from READMEs, issue comments and chat messages without thinking. Treat your IDE's browser surface the same way you treat email attachments from strangers.

6. Separate identities for personal and work

If you contribute to open source on the same GitHub account that has access to your employer's private repos, a single token theft compromises both. Use separate accounts and separate VS Code profiles. VS Code's profile feature exists for exactly this.

The bigger shift: developers are now a security team

The uncomfortable truth in the VS Code disclosure is that there's no clean fix for the category. As long as IDEs need to authenticate to cloud services, hold tokens locally, and interoperate with browsers, there will be more bugs like this one. Microsoft and GitHub will patch them. Researchers will find new ones.

What changes is the assumption developers have to operate under. The old mental model — "my laptop is safe, the server is the target" — is finished. The new model is closer to what security teams have been saying for years: assume the endpoint will be compromised, and design your access, tokens and workflows so that compromise is contained.

That means short-lived credentials, scoped permissions, hardware-backed keys, mandatory reviews on workflow changes, and a healthy paranoia about anything that wants to open in your editor. It's more friction than most of us would like. The alternative, as this VS Code bug demonstrated, is one click between business as usual and explaining to a client why their source code is on a Telegram channel.