One Click in VS Code Steals Your GitHub Token — the Researcher Skipped Coordinated Disclosure

This is two stories in one: a clickable link that can hand an attacker write access to your private code, and the latest escalation in a disclosure war that keeps dropping near-zero-notice Microsoft proof-of-concepts onto defenders.

REDMOND, WASHINGTON — Security researcher Ammar Askar has disclosed a one-click attack against Visual Studio Code's GitHub.dev — the browser-based version of the editor — that lets an attacker steal a victim's GitHub OAuth token, a credential carrying full privileges across every repository the user can access, including private ones. Per The Hacker News, SecurityWeek and The Record (reporting dated June 3 and 4, 2026), the exploit requires nothing more than getting the target to click a crafted link. Askar published full technical details and a working proof-of-concept on his personal blog, giving a GitHub security contact roughly one hour's notice and explicitly criticizing Microsoft's vulnerability-disclosure process.

The exploit chain is the kind of subtle, multi-step sequence that makes a single click so dangerous. A crafted GitHub.dev link points to a repository containing a malicious Jupyter Notebook; when the victim opens it, GitHub.com automatically posts an OAuth token to the GitHub.dev session. Hidden HTML inside the notebook then runs attacker-controlled JavaScript that fires a simulated keyboard shortcut, which VS Code accepts as though the user had triggered it — installing a rogue extension that silently exfiltrates the token and enumerates every private repository the victim can reach.

What Happened

Per the reporting, the attack turns ordinary developer workflows against the user. GitHub.dev is a zero-install, browser-based VS Code environment that opens a repository directly in the browser, and to function it is handed an OAuth token scoped to the signed-in user. Askar's chain begins with a link that points GitHub.dev at a repository he controls, which contains a malicious Jupyter Notebook. When the victim clicks the link and the notebook opens, GitHub.com automatically posts the OAuth token into the GitHub.dev session — and that token carries broad privileges across every repository the user can access, public and private alike.

From there the exploit escalates inside the editor. The notebook hides HTML that allows attacker-controlled JavaScript to execute, and that script fires a simulated keyboard shortcut. VS Code treats the synthetic keystroke as a legitimate user action, which is enough to install a rogue extension. The extension then exfiltrates the OAuth credential and enumerates the victim's private repositories. The whole sequence runs from a single click, with no password prompt and no obvious sign to the user that anything has happened. Askar said he went public after Microsoft's Security Response Center silently fixed an earlier issue he had reported — without crediting him and while denying it had any security impact — releasing this proof-of-concept with about an hour's warning to a GitHub security contact.

The Mechanism: A Synthetic Keystroke Inside a Trusted Editor

The cleverness of the chain is that every step abuses a legitimate behavior. Handing GitHub.dev an OAuth token is by design — the editor needs it to read and write the repo. Rendering a notebook is a core feature. Accepting a keyboard shortcut is normal editor behavior. The exploit stitches these together so that hostile content in a notebook can drive the editor to install an extension and lift the token, all under the cover of actions the editor considers routine. Microsoft has acknowledged the flaw and says a fix is in progress, and in the interim it applied stopgaps: a confirmation prompt when a developer opens notebooks in web VS Code, and a change that no longer lets the trusted-publisher requirement be skipped by commands. Those measures raise the bar for the specific chain Askar demonstrated, but the underlying lesson — that a single click can become code execution inside a credentialed editor — is the part defenders should internalize.

Why a Stolen GitHub Token Is a Supply-Chain Problem

A GitHub OAuth token with read-write access to private repositories is not just a confidentiality risk; it is a write primitive over an organization's source code. An attacker holding such a token can read proprietary code and secrets, and — depending on branch protections — push changes that flow downstream to everyone who builds from the repository. That is the same blast radius The CyberSignal has documented in its developer-credential and CI/CD coverage, from the codexui-android npm package quietly stealing OpenAI Codex tokens to the TeamPCP breach that exfiltrated 3,800 internal repositories through one poisoned VS Code extension. A click-to-token attack against a browser editor slots neatly into that pattern: the credential is the crown jewel, and the editor is the new soft entry point.

The Disclosure War Escalates Again

Beyond the technical risk, this disclosure is the newest entry in a confrontation The CyberSignal has tracked all spring between researchers and Microsoft over how the company handles vulnerability reports. Askar's near-zero-notice release follows Microsoft's public condemnation of uncoordinated zero-day disclosures, which it said leaves customers at 'unnecessary risk', and the more theatrical Chaotic Eclipse pledge of a July 14 Windows exploit drop. Researchers increasingly justify minimal-notice PoCs as a protest against a disclosure process they see as dismissive — and whatever the merits of either side, the practical consequence for defenders is the same: working exploit code for Microsoft-ecosystem flaws may land before, or instead of, a coordinated fix.

Scope and Impact

The exposed population is, in principle, anyone who uses GitHub.dev while signed in — which is to say a large share of professional developers, since the browser editor is a click away from any repository on GitHub. The precondition is social: the victim has to open a crafted link. But developers click repository links constantly, often from issues, pull requests, chat and email, and a 'click to open in the editor' lure is well within the range of plausible phishing. The value of the prize — a token with write access to private code — makes the target population worth the attacker's effort, particularly maintainers and engineers at organizations whose code is itself a supply-chain dependency for others.

The structural risk is the breadth of the OAuth token's scope. Because the credential reaches every repository the user can access, the impact of a single successful click scales with the victim's permissions: a maintainer with write access across an organization is a far richer target than a developer with access to one project. That is why least-privilege token design and tight branch protections matter as much as the editor fix — they bound what a stolen token can actually do, independent of how the token was taken.

A few specifics are still open and should be confirmed against vendor advisories: whether the flaw has been assigned a CVE, the precise status and completeness of Microsoft's forthcoming fix beyond the interim stopgaps, and whether GitHub has issued token-scope or revocation guidance for potentially affected users. Askar's account of the prior-report history is the researcher's characterization; Microsoft's own framing of that exchange has not been independently detailed in the reporting reviewed here, and The CyberSignal labels it as one side's account rather than an established fact.

Response and Attribution

For developers and engineering organizations, the immediate guidance is behavioral and structural. Brief developers that unsolicited links which open editor or web-IDE flows — 'click to open in VS Code / GitHub.dev' — can be weaponized, and should be treated with the same suspicion as any other phishing lure. Rotate GitHub tokens and review OAuth and GitHub App authorizations, and move to fine-grained, least-privilege tokens with short lifetimes so that a stolen token's blast radius is small and its window brief. Enforce branch protection and signed commits so that a stolen write-capable token cannot silently push to protected branches, and monitor for anomalous repository access or pushes from unfamiliar locations or tokens.

For security leaders, the broader action is to plan for the no-notice-disclosure reality. Assume that proof-of-concepts for Microsoft-ecosystem bugs may land before patches do, and pre-stage the detections and communications that pattern requires: a watch on the relevant researcher and vendor channels, a triage path for 'PoC public, fix pending' situations, and an incident-response plan that does not assume a coordinated-disclosure timeline. The same discipline applies to the wider CI/CD attack surface — the lesson of the Megalodon campaign that backdoored 5,561 repositories through poisoned workflows is that source-control and build-system credentials are high-value targets that warrant their own monitoring.

On attribution, there is no threat actor here: this is a researcher disclosure, not an observed attack, and there is no reporting of in-the-wild exploitation of the chain at the time of writing. The contested element is the disclosure dispute between Askar and Microsoft, which The CyberSignal presents as a documented disagreement rather than a settled account of who acted reasonably. The defender takeaway does not depend on adjudicating that dispute: least-privilege tokens and a comms plan for near-zero-notice PoCs are the right posture regardless of how the disclosure debate resolves.

The CyberSignal Analysis

Signal 01 — The Credential Is the Crown Jewel

The recurring lesson across this year's developer-tooling incidents is that the prize attackers want is the credential, not the code directly. A GitHub OAuth token with write access to private repositories is a master key: it reads proprietary source, exposes embedded secrets, and — absent branch protections — can push downstream to everyone who builds from the repo. Defenses that bound the credential's power, namely fine-grained least-privilege tokens, short lifetimes and signed-commit enforcement, do more to limit this class of attack than chasing each individual editor flaw, because they shrink the payoff of any single theft.

Signal 02 — A Click Is Now an Execution Primitive

The exploit's most important property is that it converts a single click into code execution inside a trusted, credentialed editor. That collapses the comfortable distinction developers draw between 'just opening a file' and 'running something.' When hostile content in a notebook can drive the editor to install an extension and lift a token, the safe assumption is that opening attacker-controlled content in a web IDE is equivalent to executing attacker code with your permissions. Microsoft's interim confirmation prompts acknowledge exactly this — they reintroduce a human decision into a flow that had become click-through.

Signal 03 — Defenders Must Plan for Disclosure Without Notice

Whatever one thinks of researchers dropping Microsoft PoCs with an hour's warning, the trend is now a planning input rather than an anomaly. Security teams that assume a coordinated-disclosure timeline — patch first, details later — will keep getting caught flat-footed. The durable response is operational: monitor the channels where these drops happen, build a triage path for 'exploit public, fix pending,' and stage detections and customer communications in advance. The disclosure war is unlikely to cool soon, so the realistic move is to treat near-zero-notice PoCs as a standing condition of the Microsoft ecosystem and prepare accordingly.

Sources