The post walks through a one-click attack against the web versions of VS Code used at github.dev and vscode.dev. The core issue was not a generic GitHub compromise. It was a chain: a malicious page could get a victim into the web editor, abuse extension installation and command execution behavior, and then extract the GitHub token that github.dev auto-issued to the session. The writeup also argues that a previous, similar VS Code report was mishandled by Microsoft Security Response Center, which is why this one was disclosed publicly instead of going through the usual private path. Shortly after, Microsoft shipped a stopgap fix that adds confirmation for opening notebooks in web VS Code and blocks commands from bypassing trusted publisher checks.
Browser-based developer tools are collapsing editor, identity, and package-supply-chain risk into one surface, so token scoping and extension isolation now matter as much as traditional code security.
Alarmed and critical. People found the exploit credible and well explained, but the sharper anger was aimed at broad GitHub token exposure in github.dev, the weak isolation model for VS Code extensions, and Microsoft’s reputation for mishandling security reports.
01 The real failure was token scope, not just the specific exploit path.
If github.dev only received a temporary per-repository token, the same extension abuse would be contained to one repo instead of exposing every repository and API action available to the logged-in GitHub account. Codespaces already uses that narrower model, which undercuts the idea that broad session power is unavoidable.
Least-privilege tokens would have turned an account takeover bug into a much smaller repo-level incident. GitHub already has the pattern in production elsewhere.
02 VS Code’s extension model is still basically 'install another app and hope for the best.
' Extensions get broad runtime access and ship large dependency trees, so the security problem is not publisher trust prompts alone. Once an editor is also a package host, automation hub, and credential broker, every extension becomes part of your trusted computing base.
Extension ecosystems need real isolation, not just marketplace trust signals. Treating plugins like harmless add-ons is no longer defensible.
03 The exploit worked because the browser protections only closed the obvious door.
Content Security Policy blocked running JavaScript from a local workspace extension, but the extension manifest could still be read and used to register a keybinding that triggered installation of the real malicious extension without the usual publisher check. That is a classic chain bug where each individual safeguard looks reasonable and still fails in composition.
Security controls that are sound in isolation can collapse when features compose. Browser IDEs need threat modeling at the whole-workflow level, not per-feature reviews.
04 Hardware-backed credentials do not save you once the host is compromised enough to steer user actions.
A YubiKey can block silent signing, but malware can queue a different operation and wait for a normal touch event, which means the user still authorizes something they never actually verified. The same logic explains why hardware wallets have screens and explicit transaction details.
Touch-to-confirm is not the same as informed confirmation. Secure hardware still depends on the host giving the user an honest prompt.
01 Public disclosure was not obviously justified just because MSRC had been painful before.
GitHub’s HackerOne program is separate and by the researcher’s own account had been good to work with. The rebuttal is that GitHub previously bounced a related report back to MSRC as out of scope, which makes the process failure look structural rather than personal.
The strongest case against the disclosure is that the cleaner path was to try GitHub again first. The strongest reply is that prior handoffs had already shown the boundary between GitHub and Microsoft to be broken.
02 Some of what looks like malicious bug triage may just be scale and internal coordination failure.
Security teams handling thousands of reports will prioritize currently reproducible issues, and if engineers quietly patched a bug first, the triager may genuinely see only a dead report. That does not excuse the outcome, but it does shift some blame from bad faith to broken process.
Large vendor bug handling can fail without anyone making an explicit decision to bury a report. For researchers, the effect is still the same.
03 The headline overstates the impact if read as a general VS Code compromise.
The exploit targeted the web deployments at github.dev and vscode.dev, not the desktop editor as such, and that distinction matters because the identity and token model are what made the GitHub theft angle so severe.
This was a web VS Code and GitHub session problem, not a blanket desktop VS Code token-stealing bug.