Topic starter
09/07/2026 9:33 am
TL;DR: Malicious VS Code extensions can silently inherit GitHub OAuth sessions, plant an SSH key, and survive token revocation, password rotation, and uninstall, leaving persistent repository access even after standard incident response, according to Knostic. The core failure is an authentication model that assumes revocation closes access when identity can be re-established through another path.
Editorial analysis by NHI Mgmt Group, based on content published by Knostic: “Revoking Your Token Won't Save You: The VS Code Attack That Installs a Permanent GitHub Backdoor”.
Key questions
Q: What breaks when a malicious VS Code extension can inherit a GitHub session silently?
A: Revoking the original OAuth token may not end access if the extension has already created a second authentication path.
Q: Why does token revocation fail when an attacker adds an SSH key to GitHub?
A: Because revocation only removes the OAuth path, not every active credential bound to the account.
Q: How can security teams tell whether an IDE extension compromise is still active?
A: Look for persistence artifacts, not just the stolen token.
Practitioner guidance
- Check GitHub SSH keys before closing the incident Search account settings for any key titled vscode-recovery or carrying the comment implant@poc, then remove anything you did not create yourself.
- Revoke every GitHub authorization tied to the IDE Review authorized OAuth apps and remove access from any extension or tool that could have inherited the shared session.
- Rotate repository and workflow secrets after key removal Treat .env files, .env.local files, and GitHub Actions secret names as compromised if the extension had access to the account.
Bottom line: The article shows that a malicious VS Code extension can reuse a shared GitHub session and survive the normal closure steps teams expect after a compromise.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
09/07/2026 9:35 am
Shared IDE authentication creates an identity reuse problem, not just an extension-risk problem: When one extension can silently inherit another extension's GitHub session, the platform has collapsed the boundary between software packages and account authority. That means review, uninstall, and token revocation are no longer sufficient as isolated controls. Practitioners have to treat the IDE as part of the identity plane, not a neutral execution environment.
A question worth separating out:
Q: Should developer teams treat VS Code extensions as part of identity governance?
A: Yes, because extensions can acquire and reuse non-human credentials that reach source code and secrets. Governance should cover who can install extensions, how session reuse is controlled, and how inherited access is revoked. If the tool can act through a shared identity, it belongs in the identity boundary.
👉 Read our full editorial: VS Code extension persistence breaks standard GitHub token response