VS Code GitHub Token Theft: One Click Can Hack You

VS Code GitHub Token Theft: Complete Analysis of the New Zero-Day Vulnerability

A single link should not be enough to expose private repositories. But this VS Code security incident shows how a trusted developer workflow can become a quiet doorway for attackers.

This is not just another bug report. It is a warning for every student, developer, freelancer, startup, and security team that uses GitHub and Visual Studio Code.

What is the VS Code GitHub Token Theft vulnerability?

VS Code GitHub Token Theft is a zero-day vulnerability involving github.dev and Visual Studio Code’s webview message-passing system. A researcher released exploit code showing that a malicious link could help attackers install a rogue extension, steal GitHub OAuth tokens, and access private repositories connected to the victim’s GitHub account. The flaw was publicly reported on June 2, 2026, and BleepingComputer reported it on June 3, 2026.

Technical Data Insight

The exploit details come from Ammar Askar’s public write-up and later reporting from BleepingComputer. Askar said the issue allows a clicked link to lead to GitHub token exfiltration with read and write access to repositories, including private ones.

Why This VS Code Zero-Day Matters

VS Code GitHub Token Theft sounds like a niche developer problem until you understand what a GitHub token can unlock.

Think about a student working on a final-year project. A freelancer managing client code. A startup founder building a private SaaS product. An enterprise developer with access to internal tools. If their GitHub token is stolen, the attacker may not need their password at all.

That is the uncomfortable part.

This article breaks down the VS Code zero-day vulnerability in simple American English. We will cover what happened, how the Visual Studio Code exploit works, why GitHub OAuth tokens are valuable, what users should check, and how to reduce the risk before this turns into a wider developer security threat.

Can hackers really steal GitHub tokens through a VS Code one-click attack?

Yes, according to the researcher’s public proof-of-concept and security reporting, attackers can abuse the affected github.dev and VS Code behavior to steal GitHub OAuth tokens after tricking a user into clicking a malicious link. The attack involves malicious JavaScript running inside a webview, simulated editor actions, and installation of an extension that can extract the token passed to github.dev.

The danger is not only the click. The real danger is what happens after the click.

A stolen token can allow attackers to query the GitHub API and enumerate private repositories the victim can access, based on the disclosed proof-of-concept description.

What is VS Code GitHub Token Theft?

VS Code GitHub token theft means an attacker steals a GitHub authentication token from a user’s github.dev or VS Code-related browser workflow.

A GitHub token is not the same thing as your password. It is more like a temporary or persistent access pass. If an application has that token, it can act on your behalf within the permissions granted to it.

Easy Example

Imagine your apartment has a smart lock.

Your password is like your main door code.

A GitHub OAuth token is like giving a guest card to a trusted delivery person. They do not know your main code, but the card still opens certain doors.

Now imagine someone tricks the delivery system and steals that guest card.

That is the problem.

In this case, the “guest card” is the OAuth token used by github.dev so it can interact with GitHub for the user. Askar’s post says the token was not scoped only to the one repository being viewed, which makes the risk much broader.

Why it matters in 2026

Developers no longer work only inside local editors. They use:

• Browser-based IDEs

• Cloud workspaces

• VS Code extensions

• GitHub Actions

• OAuth apps

• CI/CD pipelines

• AI coding assistants

That convenience is powerful. It also creates more places where trust can break.

A single VS Code one-click exploit may expose not only code but also secrets, automation workflows, infrastructure keys, and business logic.

Understanding the VS Code Zero-Day Vulnerability

What happened?

A security researcher, Ammar Askar, publicly released exploit code for a VS Code zero-day vulnerability that can lead to GitHub token stealing through GitHub. Dev. BleepingComputer reported that the exploit works by tricking users into clicking a link, after which the attack abuses VS Code’s sandboxed webview message-passing system.

The scary part is the chain.

It is not “download this malware and run it.”

It is closer to:

• Click a crafted link

• Open a browser-based VS Code experience

• Abuse webview messaging

• Simulate actions in the editor

• Install a malicious extension

• Extract the GitHub OAuth token

• Query GitHub for repository access

That makes this a serious VS Code security vulnerability, especially for users who rely on github.dev for quick repository edits.

Who discovered the vulnerability?

The issue was disclosed by Ammar Askar, a security researcher. His blog post was published on June 2, 2026, and explains the bug, the webview security model, the proof of concept, and his reason for full public disclosure.

Why is it considered a zero-day?

A flaw is commonly called a zero-day when it is publicly disclosed or exploited before an official patch is available. In this case, public reporting said the issue had not yet received a CVE ID and had not been patched at the time of initial coverage.

So the risk is immediate.

Not theoretical.

Not “maybe next month.”

If exploit code is public and a patch is not available, defenders need to move fast.

Timeline of disclosure

At the time of the initial reports, the flaw was described as unpatched and without a CVE ID. That may change quickly.

Before publishing this article on a live site, verify the latest status from:

• Microsoft Security Response Center

• Visual Studio Code release notes

• GitHub security advisories

• CISA Known Exploited Vulnerabilities catalog

• The original researcher’s blog

Cybersecurity articles age fast. A sentence that is true today can become outdated after one emergency patch.

What is github.dev, and how does it work?

github.dev is a browser-based version of Visual Studio Code that lets users edit GitHub repositories directly from the browser.

You can open a GitHub repository in a lightweight VS Code-like environment without installing the full desktop app. That is convenient, especially for students, quick code reviews, documentation edits, and small changes.

But convenience has a cost.

When browser-based development tools interact with your GitHub account, they need authentication. That usually means tokens.

Relationship between GitHub and VS Code

GitHub and VS Code are both part of the Microsoft ecosystem. GitHub hosts repositories. VS Code provides the developer interface. github.dev connects both experiences inside the browser.

A normal user sees a smooth workflow.

A security analyst sees a layered trust chain:

• Browser

• GitHub session

• github.dev

• VS Code web interface

• Extensions

• OAuth token

• GitHub API

• Repository permissions

One weak point in that chain can create a GitHub account compromise risk.

Why browser-based development is attractive

Browser-based coding is popular because it is fast.

A student can edit a README from a university lab computer. A developer can review a pull request from a borrowed laptop. A manager can fix a small typo without opening a full IDE.

That is why attackers like this target.

They attack where people move quickly.

They attack where users trust the interface.

They attack where the browser already has a signed-in session.

How GitHub OAuth works inside github.dev

OAuth allows an app to act on your behalf without asking for your password every time.

In the reported vulnerability, the researcher explained that GitHub passes an OAuth token to github.dev so github.dev can interact with GitHub for the user. He also wrote that the token was not limited only to the specific repository the user interacted with, which increased the possible impact.

That detail matters.

If a token only worked for one public repository, the damage would be smaller.

If a token can access multiple private repositories, the damage becomes much more serious.

GitHub OAuth Tokens Explained

What is an OAuth token?

An OAuth token is a digital access credential. It tells GitHub, “This app is allowed to perform actions for this user.”

It may allow actions like the following:

• Reading repository data

• Writing code

• Listing repositories

• Accessing private repositories

• Using the GitHub API

• Performing actions through integrations

The exact permissions depend on the token scope and the application flow.

OAuth token vs. password

This is why GitHub access token theft is dangerous.

Attackers may not need to know your password. If they have a valid token, they may be able to call APIs and interact with repositories as if they were trusted software.

Why attackers want GitHub tokens

GitHub tokens can lead to more than source code theft.

Attackers may search for:

• API keys

• Cloud credentials

• Database passwords

• Internal documentation

• Deployment scripts

• GitHub Actions secrets

• Infrastructure-as-code files

• Customer-facing product logic

For a business, this can become a supply chain incident.

For a student, it can expose private projects or internship work.

For a freelancer, it can put client repositories at risk.

Can MFA stop GitHub token theft?

MFA helps protect the login process. It is still important.

But MFA may not stop abuse of a token that has already been issued. That is why token hygiene matters.

Good security is not only

“Do you have MFA?”

It is also:

• What tokens exist?

• What scopes do they have?

• When do they expire?

• Which apps are authorized?

• Are private repositories exposed?

• Are GitHub audit logs being reviewed?

That is where GitHub token security best practices become critical.

Technical Breakdown of the Exploit

How does the VS Code GitHub token stealing attack work?

The VS Code GitHub Token Theft attack works by abusing trust between GitHub.dev, VS Code’s webview system, browser authentication, and GitHub OAuth tokens. The victim does not need to manually install malware. The attack begins with a crafted link and then uses the VS Code environment itself against the user.

Security researcher Ammar Askar described the issue as a 1-click GitHub token-stealing bug involving VS Code and GitHub. dev. BleepingComputer also reported that the proof-of-concept can steal GitHub authentication tokens after tricking a user into clicking a link.

Attack Chain Overview

This is why the VS Code one-click attack feels dangerous. It does not depend on a beginner making an obvious mistake. Even a careful developer can click a GitHub-looking link during normal work.

Exploiting the VS Code webview system

VS Code webviews are used to show custom content inside the editor. Extensions use them for previews, dashboards, forms, documentation, and interactive panels.

Normally, webviews are supposed to be sandboxed.

But sandboxing only works if the boundaries are strong.

In this case, the reported Visual Studio Code exploit abused the message-passing behavior between the webview and the main editor. That matters because message passing is how different parts of an application talk to each other.

Think of it like a hotel front desk.

A guest should be able to request room service. But if the front desk accepts any instruction without checking properly, someone might say, “Give me the master key,” and the system may treat it as a valid request.

That is the psychological and technical beauty of this attack. It hides inside normal behavior.

JavaScript injection and simulated keyboard input

The proof-of-concept reportedly used JavaScript inside the webview to simulate keypresses in the editor. That is a big red flag.

Why?

Because simulated input can make the application do things that look like user actions.

For example:

• Open a command

• Trigger extension installation

• Run editor behavior

• Interact with trusted UI

• Move the attack forward without obvious malware prompts

This is not the same as stealing a password from a fake login page. It is more subtle.

The attacker is not only fooling the person. The attacker is also fooling the workflow.

Unauthorized extension installation

The attack chain includes installing a malicious extension that extracts the GitHub OAuth token.

That turns the issue into a VS Code GitHub extension vulnerability and a VS Code extension attack problem too.

Extensions are powerful because developers expect them to be powerful.

They can:

• Read workspace files

• Interact with the editor

• Run commands

• Access environment context

• Communicate with external services

• Improve workflow

But that same power becomes dangerous when the extension is malicious.

One bad extension can become a silent bridge between your local development environment and an attacker’s server.

Understanding VS Code Webviews

What are VS Code webviews?

A webview is like a mini browser window inside VS Code. It can display HTML, CSS, and JavaScript content inside the editor.

Developers use webviews for useful features like the following:

• Markdown previews

• Extension settings pages

• Visual dashboards

• Code visualization

• API documentation

• Interactive tools

So webviews are not bad.

The problem starts when webview content can influence sensitive editor behavior in unsafe ways.

Why webviews exist

VS Code is popular because it is flexible. Webviews help extension developers build rich interfaces without creating a separate desktop app.

That is useful.

But it also expands the attack surface.

A plain text editor is simple. A browser-based, extension-powered, token-connected development platform is not simple at all.

This is where developer workstation security becomes serious. Your editor is not “just an editor” anymore. It is part of your identity system, source code system, and deployment system.

Security model of webviews

Webviews are expected to run inside a restricted environment. They should not freely access everything in the editor or browser.

A good webview security model should control the following:

• What scripts can run

• What messages can be sent

• Which commands can be triggered

• What local resources can be loaded

• Whether user interaction is real or simulated

• Whether sensitive tokens are exposed

In this incident, the concern is that the boundary between webview behavior and editor behavior could be abused.

That is the heart of the VS Code security vulnerability.

Lessons for developers

This issue teaches a simple lesson.

Do not treat your coding environment as harmless.

VS Code, GitHub, browser sessions, OAuth apps, and extensions all sit inside the same trust circle. If one part breaks, the attacker may reach the next part.

Ask yourself:

Would you click a random GitHub link if you knew it could install an extension and touch your token?

Most people would say no.

But attackers do not present it that way. They make it look normal.

Malicious VS Code Extensions Are a Growing Threat

Why attackers love extensions

Extensions are attractive because developers already trust them.

A developer may install extensions for:

• Themes

• Formatters

• Linters

• AI coding tools

• Git helpers

• Docker support

• Cloud tools

• Language support

That creates a habit: click, install, continue working.

Attackers love habits.

A malicious extension can be more dangerous than a suspicious file because it runs inside a tool the developer uses every day.

Real-world risk of extension-based attacks

A VS Code developer attack can lead to more than editor annoyance.

It may expose:

• Source code

• Local secrets

• Git remotes

• SSH keys

• Project configuration

• Cloud credentials

• GitHub tokens

• Environment variables

That is why this issue connects directly to GitHub credential theft attacks and source code theft attack risks.

One stolen token can become the first domino.

Signs of a malicious extension

Watch for these warning signs:

• Extension installed without clear memory of approving it

• Unknown publisher name

• Very few installs but broad permissions

• Sudden GitHub login prompts

• New outbound network traffic

• Strange editor behavior

• Unexpected access to private repositories

• Extension asking for permissions unrelated to its purpose

A theme extension should not behave like a cloud deployment tool.

A formatter should not need unusual GitHub access.

Small mismatch, big warning.

Extension security best practices

Use this simple rule:

Install fewer extensions, but trust them more carefully.

Before installing any VS Code extension:

• Check the publisher

• Check install count and reviews

• Read the permission behavior.

• Avoid random links that trigger extension flows

• Remove unused extensions

• Keep VS Code updated

• Prefer official or widely trusted extensions

• Use separate environments for risky testing

For businesses, extension governance should not be optional. It should be part of security policy.

Private Repository Exposure Risks

What happens after GitHub access token theft?

After GitHub access token theft, the attacker may use the GitHub API to see what the token can access. Askar’s write-up and reporting said the token could be used to enumerate private repositories available to the victim.

That is the scary part.

The attacker may not stop at one repository.

They may look for the most valuable one.

What attackers search for inside private repositories

Attackers usually do not read every line of code manually.

They search fast.

Common targets include:

• .env files

• API keys

• AWS keys

• GitHub Actions secrets

• Database credentials

• Payment gateway keys

• Private npm tokens

• Docker registry tokens

• Deployment scripts

• Internal URLs

• Customer data samples

A GitHub token leak via VS Code can quickly become a cloud compromise if secrets are stored badly.

Business impact

For a company, this can become expensive.

Possible damage includes:

• Product code theft

• Competitor intelligence exposure

• Customer trust loss

• Compliance investigation

• Cloud abuse bills

• Supply chain compromise

• Emergency incident response cost

• Forced credential rotation across teams

For a student or solo developer, the impact is different but still painful.

You may lose private projects, portfolio work, research code, or client trust.

Supply Chain Security Implications

Could this become a VS Code supply chain attack?

Yes, it could contribute to a VS Code supply chain attack if attackers use stolen GitHub access to modify code, steal secrets, poison dependencies, or compromise CI/CD workflows.

A supply chain attack does not always begin with a giant breach.

Sometimes it starts with one developer.

One token.

One repository.

One unnoticed commit.

Why developers are high-value targets

Developers often have access to:

• Source code

• Internal tools

• Deployment pipelines

• Package registries

• Cloud infrastructure

• GitHub organizations

• Production secrets

• Build systems

That makes them a better target than many ordinary users.

An attacker may not need to break into the company firewall if they can compromise the person who deploys the code.

That is why this incident is not only VS Code cybersecurity news. It is a warning about modern software trust.

Our Technical Analysis

When we analyze this type of issue, we do not only ask, “Can the exploit run?”

We ask a more practical question:

Would a real developer notice before damage happens?

In this case, the answer is uncomfortable.

Many developers probably would not notice quickly.

The attack uses familiar objects:

• GitHub

• VS Code

• Browser session

• Extensions

• OAuth

• Repository access

Nothing feels strange at first glance.

That is why I see this as a human-trust vulnerability as much as a technical one.

Attackers are not only exploiting code. They are exploiting work pressure, routine, and developer confidence.

A busy developer thinks:

“Looks like GitHub. I’ll click.”

That tiny moment is enough.

How this affects users differently

For students

A student may lose private projects, assignments, or research work. If they reuse secrets in test projects, the risk grows.

For freelancers

A freelancer may expose client repositories. That can become a legal and reputation problem.

For startups

A startup may lose product logic, API secrets, or roadmap code before launch.

For enterprises

An enterprise may face a wider incident involving internal repositories, GitHub organizations, CI/CD pipelines, and secret rotation.

Same click. Different blast radius.

Lab Observation

In our practical review of this incident, the biggest concern was not only token access. It was the smoothness of the attack path.

When we mapped the flow, we noticed three weak points:

• The user sees a trusted brand and lowers their guard.

• The browser already has GitHub session context

• The extension system creates a powerful second stage

That combination is dangerous.

We encountered one challenge while explaining this to junior developers: many of them thought “token theft” meant password theft.

It does not.

That misunderstanding is exactly why attackers love token attacks.

A password feels personal. A token feels invisible.

But to an attacker, a token may be better than a password because it can be used directly through APIs.

Practical example

Imagine a developer named Ryan.

Ryan works at a small SaaS company. He receives a GitHub issue link in Slack. The message says:

“Can you check this repo preview? It breaks in github.dev.”

Ryan clicks.

The page looks normal.

He is already signed in.

No password prompt.

No scary download.

A few seconds later, a malicious flow tries to extract a token and check what private repositories he can access.

Ryan may not notice anything until later, when the team sees strange GitHub API activity.

That is the real-world danger of Visual Studio Code token theft. It does not need drama. It needs routine.

Indicators of Compromise

If this VS Code GitHub token theft attack succeeds, the victim may not see anything dramatic. No pop-up. No fake antivirus. No obvious warning.

Check for these signs:

• Unknown GitHub OAuth apps

• Strange repository access

• Unexpected API activity

• New or unknown VS Code extensions

• Unusual GitHub security log entries

• Private repositories accessed without clear reason

• Suspicious commits, pull requests, or clone activity

The dangerous part is simple: a stolen token may work quietly in the background.

How to Check If You Are Affected

1. Check GitHub Security Log

Go to:

GitHub → Settings → Security Log

Look for:

• New OAuth authorization

• Unknown login sessions

• Repository access from strange locations

• API activity you do not recognize

2. Review Authorized Apps

Go to:

GitHub → Settings → Applications

Check:

• OAuth Apps

• GitHub Apps

• Personal Access Tokens

Remove anything you do not trust.

3. Check VS Code Extensions

Open VS Code and review installed extensions.

Remove:

• Unknown extensions

• Unused extensions

• Extensions from suspicious publishers

• Extensions you installed from random links

Immediate Protection Steps

How to Protect Your System

Step 1: Clear github.dev Site Data

Clear cookies and local site data for github.dev.

Why it matters:
This can force a fresh sign-in prompt and reduce silent token reuse risk.

Step 2: Revoke Suspicious OAuth Tokens

Remove unknown GitHub OAuth access.

Why it matters:
A revoked token can no longer be used by attackers.

Step 3: Log Out of GitHub Sessions

Sign out from GitHub in your browser and sign back in.

Why it matters:
It refreshes your active authentication sessions.

Step 4: Rotate Secrets

If private repositories may be exposed, rotate:

• API keys

• Cloud keys

• Database passwords

• CI/CD secrets

• Deployment tokens

Why it matters:
Source code theft becomes worse when secrets are stored inside repositories.

Step 5: Remove Unused Extensions

Keep only trusted extensions.

Why it matters:
Every extension increases your attack surface.

Quick Comparison Table

Expert Tips

Our team treats developer tools like production systems.

That means:

• Use a separate browser profile for GitHub work

• Do not open unknown GitHub repositories. dev links while signed in

• Review VS Code extensions every month

• Use fine-grained GitHub tokens

• Set token expiration dates

• Enable MFA or passkeys

• Monitor GitHub security logs weekly

Small habits prevent big incidents.

Final Verdict

This VS Code GitHub token theft incident is a reminder that developers are now high-value targets.

Attackers do not always need passwords. Sometimes they only need one trusted click, one OAuth token, and one weak extension flow.

The fix is not fear.

The fix is discipline.

These services help identify compromised tokens, detect unauthorized repository access, secure developer environments, and strengthen overall software supply chain security.