HN Debrief

1-Click GitHub Token Stealing via a VSCode Bug

  • Security
  • Developer Tools
  • Open Source
  • Infrastructure

The post walks through an exploit chain in vscode.dev and github.dev that ends with GitHub token theft after a single user action. The core trick is not “someone installed a sketchy extension on purpose.” It is that VS Code webviews, keyboard shortcuts, local workspace extensions, and GitHub’s automatic sign-in model could be combined so a malicious repo or redirected page nudged the browser IDE into installing code that then exfiltrated the user’s GitHub token. That matters because github.dev was running with the user’s normal GitHub account privileges, not a narrowly scoped token for just the repo they opened. So a bug reached far beyond one project.

Treat browser IDEs and coding agents as high-risk surfaces that should never hold broad, durable credentials. If your team uses github.dev, VS Code web, or similar tools, push for per-repo temporary tokens, stricter extension isolation, and an explicit review of where long-lived GitHub access is being handed out automatically.

Discussion mood

Impressed by the exploit and angry at the security posture around it. Most comments backed the researcher, criticized Microsoft’s past handling of reports, and argued that github.dev’s default broad trust and VS Code’s extension model made this kind of failure too easy to weaponize.

Key insights

  1. 01

    Codespaces already shows the safer token model

    Codespaces already issues a token scoped to the active repository, which undercuts any claim that github.dev had to inherit a full GitHub web session. That makes the problem feel less like an unavoidable tradeoff and more like a product decision that left a much larger blast radius than necessary.

    If you build browser IDEs or agent tooling, copy the Codespaces pattern. Scope credentials to one repo or one task, and expire them fast enough that a stolen token is mostly useless.

      Attribution:
    • zbentley #1
    • ammar2 #1
  2. 02

    Extensions are basically privileged apps

    VS Code extensions are not lightweight plugins in any meaningful security sense. They are bundled Node.js applications with broad access, which means every extension and every transitive dependency sits close to the user’s files, credentials, and editor state. In the browser version, that same trust spills into account-level GitHub actions when the IDE is already signed in broadly.

    Treat every extension install like adding a new executable to your fleet. Reduce extension count, isolate risky workflows in separate profiles or sandboxes, and assume supply chain review matters as much here as it does for npm packages.

      Attribution:
    • maxloh #1
    • zbentley #1
  3. 03

    Users cannot meaningfully turn this off

    The lack of a normal OAuth consent flow means users cannot simply revoke github.dev access like they would for a third-party app. On top of that, there is no repository setting to disable github.dev, so maintainers cannot remove the attack surface at the repo level even if they want a stricter posture.

    Do not assume GitHub’s defaults match your risk tolerance. If browser editing is not essential, document an internal policy against using github.dev and add controls elsewhere, such as browser policies, SSO session limits, and tighter token monitoring.

      Attribution:
    • ammar2 #1
    • jonnyysmith #1
  4. 04

    CSP blocked code but not metadata abuse

    The exploit did not need full script execution from a local workspace extension because the package metadata still let the attacker contribute a keybinding. That is a useful lesson in how partial mitigations fail. Blocking one execution path with CSP still left enough of the extension model exposed to trigger a dangerous command sequence.

    When reviewing editor or browser defenses, test what metadata and declarative hooks can still do after script execution is blocked. A narrowed primitive is often still enough to chain into something worse.

      Attribution:
    • ammar2 #1
    • thrdbndndn #1
  5. 05

    Hardware keys do not save a compromised host

    Several comments pushed back on the idea that stronger local credentials would solve this. Protected branches and manual approvals can slow automated repo abuse, but even hardware-backed authentication like YubiKey only helps if the host is trustworthy. Malware can queue a signing request and trick the user into supplying the touch at a plausible moment.

    Use hardware tokens for account security, but do not treat them as protection against malicious code already running in the same environment. Pair them with host isolation and workflow approvals that require a second person or a second device.

      Attribution:
    • digi59404 #1
    • dns_snek #1

Against the grain

  1. 01

    Public disclosure still crossed a line

    The sharpest pushback was that Microsoft’s past handling does not justify dropping a live exploit without first trying GitHub’s current HackerOne path or giving short notice before publication. That view does not defend MSRC. It argues that the people exposed by immediate disclosure were users, not the process that frustrated the researcher.

    If you run security research or a disclosure program, separate grievances about credit and severity from decisions that increase user exposure. A brief notification window can preserve pressure on the vendor without making defenders learn about the bug at the same time as attackers.

      Attribution:
    • st3fan #1
  2. 02

    Bad bounty outcomes are not enough

    One commenter argued that the strongest factual complaint here is not that Microsoft ignored the class of bug, but that it rated similar findings low and failed to credit or reward them properly. From that framing, public release becomes much harder to defend ethically because the trigger was dispute over treatment, not a vendor refusing to fix exploitable flaws.

    When your case for aggressive disclosure depends on process failures, be precise about what failed. If the vendor is fixing bugs but mishandling recognition or severity, the pressure campaign should target that process directly.

      Attribution:
    • nicce #1
  3. 03

    The bug was limited to web VS Code

    A small corrective note was that the headline could be read too broadly. The exploit applied to vscode.dev and github.dev, not to every VS Code environment. That does not make the issue minor, but it does matter for teams deciding whether the risk sits in desktop VS Code, browser VS Code, or both in different ways.

    Scope your internal response to the actual deployment model. Browser IDE sessions need immediate review here, while desktop VS Code calls for a separate assessment around local extension privileges and file access.

      Attribution:
    • cyh555 #1

In plain english

Codespaces ↩
GitHub's hosted development environments that let you open a cloud-based coding workspace from a repository.
CSP ↩
Content Security Policy, a browser security feature that restricts which scripts, images, and other resources a page is allowed to load or run.
github.dev ↩
GitHub’s browser-based code editing experience built on the web version of Visual Studio Code.
HackerOne ↩
A platform companies use to run bug bounty and vulnerability disclosure programs.
MSRC ↩
Microsoft Security Response Center, the team that handles vulnerability reports for Microsoft products.
Node.js ↩
A widely used JavaScript runtime for servers and developer tooling.
OAuth ↩
Open Authorization, a standard way for applications to let users log in or grant access without sharing passwords directly.
token ↩
A chunk of text a language model reads or generates, which is commonly used for pricing and context limits.
VS Code ↩
Visual Studio Code, a popular code editor often used for programming and data analysis.
vscode.dev ↩
Microsoft’s web-hosted browser version of Visual Studio Code.
YubiKey ↩
A hardware security key that can also be used to hold cryptographic keys for authentication or signing.

Reference links

Exploit details and fixes

Background on scoped credentials and disclosure

Related sandbox and tooling risks