# One-Click GitHub OAuth Token Theft: VS Code Attack Exposes Developer Credentials at Scale


A critical vulnerability discovered in Microsoft Visual Studio Code's GitHub integration enables attackers to steal GitHub OAuth tokens with a single user click, potentially compromising repositories, secrets, and private code across millions of developer machines. Security researcher Ammar Askar disclosed the attack this week, demonstrating how the widely-trusted development environment can be weaponized to bypass GitHub's OAuth security model entirely.


## The Threat


The attack is deceptively simple: a malicious link sent via email, chat, or embedded on a website triggers a one-click credential theft that grants attackers full read-and-write access to the victim's GitHub repositories, including private codebases, organizational resources, and sensitive configuration files. There is no additional authentication step, no warning dialog, and no indication that a token has been compromised.


Key threat indicators:


  • Victim scope: Any developer with VS Code and GitHub authentication enabled
  • Attack surface: Phishing emails, Slack messages, Discord servers, social media posts, forums
  • Access granted: Full GitHub OAuth token with repo, gist, and potentially admin privileges
  • Persistence: Stolen tokens remain valid until manually revoked, enabling sustained unauthorized access
  • Lateral movement: Compromised tokens can be used to access organizational repositories, GitHub Actions workflows, and deployment secrets

    • ## Background and Context


    ### GitHub.dev and the Web IDE


    GitHub introduced GitHub.dev, a lightweight, browser-based code editor that allows developers to browse and edit repositories directly from github.com without cloning to a local machine. The feature integrates seamlessly with VS Code through a web-based extension system, allowing developers to open a repository by pressing the period (.) key on any GitHub page or by navigating to github.dev/<owner>/<repo>.


    This convenience feature is built on VS Code's web architecture, which shares core components with the desktop application. Both versions authenticate to GitHub using OAuth tokens to enable features like commit authorship, repository cloning, and code completion.


    ### How OAuth Normally Protects Users


    Traditional OAuth flows include explicit user consent: users are directed to GitHub's login page, shown what permissions an application is requesting, and must explicitly approve the authorization. This design prevents unauthorized applications from silently accessing user credentials.


    However, VS Code's GitHub integration shortcuts some of these protections by relying on browser-stored OAuth tokens and extension-to-IDE communication protocols that were not designed to prevent malicious redirect attacks.


    ## Technical Details


    ### The Attack Mechanism


    The vulnerability exploits how VS Code's desktop application handles redirect URIs from VS Code's web extension system. Here's the attack flow:


    1. Attacker crafts a malicious link pointing to a specially formatted vscode:// URI or a GitHub.dev URL with injected parameters

    2. Victim clicks the link from an email, Slack message, or website

    3. VS Code on the victim's machine opens automatically and initiates the GitHub authentication flow

    4. A redirect parameter is injected that sends the OAuth token to the attacker's controlled server instead of VS Code

    5. The token is exfiltrated before VS Code can detect the mismatch


    The attack succeeds because VS Code does not properly validate the redirect URI destination or alert the user that their token is being transmitted to an unexpected location.


    ### Why It Works


    Several design flaws combine to create this vulnerability:


  • Implicit trust in local handlers: Windows, macOS, and Linux allow applications to register protocol handlers (vscode://), and the operating system launches them without user confirmation when a link is clicked
  • Token in memory: VS Code keeps the OAuth token in memory and automatically includes it in requests, without requiring re-authentication for sensitive operations
  • Insufficient redirect validation: The application does not validate that redirect URIs return to trusted VS Code hosts
  • No user warning: Unlike browser-based OAuth flows, there is no approval screen or confirmation that a credential is being shared

    • ## Implications for Developers and Organizations


    ### Immediate Risks


    Individual developers face exposure of:

  • Private GitHub repositories and their entire commit history
  • Secrets and configuration files stored in repos (API keys, credentials, database passwords)
  • Access to modify code, branches, and pull requests in repositories they contribute to
  • Ability to fork repositories and exfiltrate code at scale

    • Organizations face broader compromise:

  • GitHub organizational repositories and team access
  • GitHub Actions workflows (which can be modified to exfiltrate secrets or deploy malicious code)
  • Third-party applications with GitHub OAuth access (the stolen token can be used to authorize additional apps)
  • Dependency supply chain attacks (compromised accounts can inject malicious code into open-source libraries)

    • ### Attack Vectors


    Attackers are likely to distribute malicious links through:

  • Spear phishing targeting developers at high-value targets
  • Trojan horse links in GitHub issues and pull requests
  • Forum and community posts on Stack Overflow, Reddit, and security research communities where developers congregate
  • Typosquatting and lookalike URLs (e.g., "ghubdev.com" linking to the malicious URI)
  • Job recruitment scams with links to "code challenges"

    • ## Recommendations


    ### Immediate Actions


    All developers should:


    1. Review GitHub token usage: Visit [github.com/settings/tokens](https://github.com/settings/tokens) and revoke any tokens you do not actively use

    2. Enable GitHub's token expiration: GitHub now supports automatic token expiration; set tokens to expire after 30 days

    3. Upgrade VS Code to the latest version (patch released 2026-06-03)

    4. Avoid clicking unfamiliar links that claim to open code editors or development tools

    5. Review recent activity: Check [github.com/settings/security-log](https://github.com/settings/security-log) for unauthorized access


    Organizations should:


    1. Audit repository access logs: Identify any unexpected clones, pushes, or modifications

    2. Rotate secrets and API keys: Assume that any secrets stored in repositories may have been accessed

    3. Review GitHub Actions workflows: Check for unauthorized modifications that could inject malicious code into builds

    4. Enforce token policies: Require token expiration, disable personal access tokens where possible, and enforce API rate limiting

    5. Monitor GitHub API usage: Alert on unusual API calls or bulk repository access from unfamiliar IP addresses


    ### Long-Term Mitigations


  • Use GitHub's fine-grained personal access tokens instead of classic tokens, which limit permissions to specific repositories and actions
  • Enable GitHub's token alert feature (currently in beta) which notifies users when tokens are exposed in public repositories
  • Implement GitHub's branch protection rules to require reviews and status checks, preventing direct pushes even with a compromised token
  • Use machine-to-machine authentication (GitHub Apps) for CI/CD and automation, which can be more tightly scoped than user tokens
  • Consider passwordless authentication using SSH keys or GitHub's WebAuthn support instead of storing tokens in browser memory

    • ## HackWire Analysis


    This vulnerability is a watershed moment for VS Code's security model — and a reminder that developer tools, precisely because they are trusted with access to production code and deployment credentials, are high-value attack targets.


    The timing is critical: VS Code powers roughly 60% of the developer market, GitHub hosts over 100 million repositories including proprietary commercial code and open-source dependencies that millions of applications depend on. A one-click compromise of this channel means that attackers no longer need to compromise CI/CD pipelines or supply-chain build systems — they can attack developers directly and have immediate, frictionless access to the source code itself.


    What makes this particularly insidious is that it breaks a fundamental assumption in OAuth's trust model: that the *user* initiates authentication and explicitly approves what permissions an application receives. Here, the attacker removes the user from the equation entirely by automating the authentication flow and hiding the redirect destination. This is not a flaw in GitHub's OAuth implementation; it's a flaw in how a trusted application (VS Code) is willing to exchange authentication for convenience.


    The pattern fits a broader trend we've seen this year: authenticated attack surfaces are becoming more valuable than unauthenticated ones. As organizations harden perimeter security, lock down API access, and enforce MFA, attackers have shifted focus to compromising accounts that *already have* access. A developer's GitHub token is worth more than a database password — it represents trusted, legitimate access that won't trigger rate limits or anomaly detection.


    The broader implication: developer tools are now a primary attack vector for supply-chain compromise. Organizations that depend on open-source software need to think about protecting developers the same way they protect production infrastructure. Code is infrastructure.


    Organizations should treat this as a supply-chain incident waiting to happen. If an attacker compromises a maintainer's GitHub token, they have immediate, undetectable access to push malicious code to dependencies that millions of applications use. This is not theoretical — we've seen exactly this attack pattern in the log4j, xz-utils, and colors.js incidents.


    The fix for VS Code is straightforward: validate redirect URIs, require explicit user approval before exfiltrating tokens, and implement safeguards similar to browser-based OAuth flows. But the deeper fix requires a mindset shift — developer tools must be treated as security-critical infrastructure, not just productivity conveniences.


    — HackWire Editorial


    ## Related Coverage


  • Read more in our [Tools](https://www.hackwire.news/category/tools) coverage
  • Cross-reference with [Breaches](https://www.hackwire.news/category/breaches) and [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)