Zero-Click? No, One-Click: GitHub Token Theft via VS Code & github.dev
Has anyone reviewed the latest disclosure from Ammar Askar regarding the github.dev integration? It's a pretty nasty one-click attack that targets the OAuth token used by Visual Studio Code in the browser.
The core issue lies in how the web-based VS Code environment initializes workspaces when loaded via a malicious link. By crafting a specific URL, an attacker can force the environment to expose the active session token, which often has read/write permissions to private repositories.
It seems the vulnerability exploits the authentication handshake that persists when transitioning between the standard GitHub interface and the github.dev editor. If you're auditing your environment right now, you'll want to check the scope of your active tokens immediately.
You can identify potentially compromised tokens by checking your recent authorization sessions:
curl -s -H "Authorization: token GITHUB_TOKEN" \
https://api.github.com/authorizations | jq '.[] | {id: .id, app: {name: .app.name}, updated_at: .updated_at, scopes: .scopes}'
(Replace `GITHUB_TOKEN` with your valid token for the check).
I've already revoked my web sessions, but I'm wondering if this impacts the desktop client's `vscode://` URI handler as well, or if it is strictly limited to the web interface. Has anyone seen active exploitation in the wild yet?
We saw a similar pattern during a red team exercise last month. The web editor is convenient, but it blurs the line between a trusted application and a browser context.
From an SOC perspective, detecting this is hard because the traffic originates from a legitimate user agent and IP. You have to rely on the 'Odd travel' logic or repo access anomalies. We recommend checking for pushes to unexpected branches:
GithubAuditLog
| where Action == "push"
| where Repo == "YourPrivateRepo"
| project TimeGenerated, Actor, Branch, Ref
If you see devs pushing to `main` from `github.dev` unexpectedly, flag it.
I haven't confirmed the CVE ID yet, but the mechanism sounds like a specific variation of a CSRF or confused deputy attack against the authorization flow.
For the time being, I've advised my devs to strictly use the desktop IDE and disable the github.dev feature entirely via org settings if possible. It's a bit of a blunt instrument, but the risk of losing private source code outweighs the convenience of a quick browser edit. Also, ensure your tokens don't have repo scope unless absolutely necessary; scope reduction is your best defense here.
This highlights a major trust issue for our SaaS clients. We’re advising immediate revocation of any suspicious github.dev sessions. You can audit active authorizations via the GitHub CLI to check for tokens with write access granted to the web editor.
gh api user/authorizations --jq '.[] | select(.app.name | contains("Visual Studio Code"))'
Regular audits of these scopes are becoming essential since this browser-based attack vector is hard to block at the perimeter.
Building on Tom's point, we’ve found that monitoring for repo.git_protocol events works well to spot unauthorized web editor access. If you use the GitHub CLI, you can pipe the audit log to look for these specific anomalies:
gh api /enterprises/YOUR_ENTERPRISE/audit-log --paginate -q '.[] | select(.action == "repo.git_protocol") | .actor'
Building on the detection points, for teams using Azure Sentinel to ingest GitHub Audit Logs, here is a specific KQL query to hunt for those repo.git_protocol anomalies. It helps identify when the web editor is used unexpectedly by specific actors:
GithubAuditLog
| where Action == "repo.git_protocol"
| extend Editor = iff(UserAgent contains "github.dev", "WebEditor", "CLI")
| summarize Count=count() by Actor, Editor, bin(Timestamp, 1h)
| where Editor == "WebEditor" and Count > 5
This filters for high-frequency usage from the web editor, which often indicates scripted abuse or an attack chain rather than normal editing.
To complement the detection strategies, consider enforcing IP restrictions on your OAuth apps. By scoping token usage to known GitHub IP ranges or specific corporate egress points, you limit the blast radius if a token is exfiltrated. You can script an automated pull of GitHub's current IP ranges to update your firewall rules dynamically:
curl https://api.github.com/meta
This adds a vital layer of network-level defense around the authentication flow.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access