VS Code extension persistence breaks standard GitHub token response

At a glance

What this is: Knostic's research shows that malicious VS Code extensions can abuse shared GitHub authentication to steal tokens and create SSH-based persistence that survives standard revocation steps.

Why it matters: This matters because incident response for developer tooling must account for secondary access paths, not just the token that first exposed the account.

Context

VS Code extension trust is an identity problem, not just a code review problem. If one extension can inherit another extension's GitHub session, then the workspace has a shared authentication boundary that attackers can exploit without user interaction.

The article centres on a non-human identity exposure path: a developer's GitHub session becomes reusable across extensions, and a planted SSH key keeps account access alive after ordinary token response. That makes the compromise persist across the lifecycle steps teams usually rely on to close an incident.

The starting position is atypical in technique but typical in governance failure. The pattern is not unique to one malicious extension; it exposes a platform-level assumption that session revocation alone is enough to end access.

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. In this attack pattern, the real failure is account-level persistence through SSH key implantation, which keeps repository access alive even after uninstall and password rotation. Teams must verify whether alternate credentials were added before closing the incident.

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. If an attacker has already planted an SSH key, they can keep accessing repositories even after the original token is gone. Effective containment must remove all attacker-created credentials, not just the first one discovered.

Q: How can security teams tell whether an IDE extension compromise is still active?

A: Look for persistence artifacts, not just the stolen token. Unexpected SSH keys, startup-time authentication calls, and extension traffic to attacker infrastructure show that the account may still be reachable through another path. If those indicators remain, the compromise is not closed.

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.

Technical breakdown

How shared GitHub sessions become extension-level access

VS Code's authentication API can return a stored GitHub session to any extension that calls getSession with the right provider and scopes. When silent access is allowed, the user sees no approval prompt, so the malicious extension inherits an existing OAuth grant rather than stealing a password directly. The critical detail is that the extension is not breaking GitHub authentication in isolation; it is reusing a shared local session established by another extension. That means the trust boundary is the IDE runtime, not the individual extension package.

Practical implication: Treat shared IDE authentication as a governed access path, not a convenience feature.

Why token revocation does not end the compromise

Revoking the OAuth token removes only one credential path. In this attack, the extension also plants an SSH key on the victim's GitHub account, creating a second access method that survives token rotation, password changes, and extension removal. This is a persistence pattern, not a one-time credential theft. Once the attacker owns an approved SSH key on the account, repository access can continue independently of the original OAuth session. The relevant control failure is incomplete session closure across identity channels.

Practical implication: Validate and remove all secondary account credentials, not just the token that triggered detection.

How extension persistence turns into repository exposure

After obtaining GitHub access, the extension enumerates repositories, reads recent .env and .env.local files, and collects workflow and secret metadata. That broadens the impact from account compromise to source-code and secrets exposure across the developer's active repository set. Because the malware runs on startup and uses server-side key generation, each victim can receive a unique persistence artifact, which makes simple hash-based hunting less useful. The security lesson is that developer tooling can become an identity bridge into secrets-rich codebases.

Practical implication: Monitor extension behaviour, SSH key changes, and repository-level secret exposure as one incident chain.

Threat narrative

Attacker objective: The attacker wants durable GitHub repository access that survives ordinary incident response and can be reused to harvest secrets and source code.

1. Entry begins when a malicious VS Code extension calls the shared GitHub authentication session and receives an existing OAuth token without user awareness.
2. Escalation occurs when the extension uses that token to enumerate repositories and then plants an attacker-controlled SSH key on the GitHub account.
3. Persistence is established because the planted SSH key survives token revocation, password rotation, and extension uninstall.
4. Impact is repository-wide access to source code, .env contents, workflow metadata, and other developer secrets.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

SSH-key persistence is the decisive failure mode here: The compromised token is only the first foothold, but the planted SSH key makes the access durable. This breaks the common assumption that OAuth revocation closes developer-account compromise. The implication is that account response must account for every live credential path, including keys added after the original grant.

Need-to-know access is being violated at the tooling layer: The extension reads repository metadata and recent .env files from multiple active projects, not just the current workspace. That creates a broad blast radius from a single IDE session and shows why source control, secrets exposure, and extension trust belong in one governance conversation. Practitioners should classify the IDE extension surface as a privileged path into code and secrets.

Identity blast radius is the right named concept for this attack class: A single shared GitHub session in the IDE can spill into repository access, SSH persistence, and secrets exposure across multiple projects. That makes the security question less about whether an extension is malicious and more about how far a compromised session can propagate. The practitioner conclusion is to bound that blast radius before the next extension inherits it.

Developer-tool governance now sits inside NHI governance: The article shows a non-human identity problem where the account is not only the developer's, but also an inherited session available to extensions. This is exactly the kind of lifecycle overlap that traditional incident playbooks miss. Teams need to govern how tooling acquires, stores, and reuses non-human credentials across the development stack.

What this signals

Identity blast radius is the right way to read this attack pattern: a single shared GitHub session can fan out from the IDE into repository access, SSH persistence, and secrets exposure. That means the response problem is not just removal of one token, but constraining how far an extension can propagate inherited identity.

The control gap is at session creation time, not only at incident response time. Once a tool can silently reuse a GitHub grant, revocation becomes reactive cleanup instead of true containment. Teams should model extension trust as a governed access pathway inside the developer workstation.

This is also a secrets-management problem because the extension reached .env files and workflow metadata after establishing Git access. If developer tooling can see source repositories, then IDE extension governance, NHI governance, and secrets hygiene need to be aligned in the same programme.

For practitioners

• 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. Treat that as the first containment step because token revocation alone does not terminate access.
• 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. Confirm that the original grant is no longer present before assuming the account is clean.
• 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. Rotate credentials in active repositories and replace any secrets exposed through local developer tooling.
• Audit extension provenance before installation Review publisher identity, install count, and review history for IDE extensions before allowing them into developer environments. Random-string publishers with no installs or reviews should be treated as a high-risk supply chain signal.
• Watch for SSH key creation as a persistence indicator Alert on unexpected POST requests to /user/keys, new SSH keys in account settings, and unusual startup-time authentication calls from extensions. Those signals show that the compromise has moved from token theft to durable account persistence.

Key takeaways

• 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.
• The persistence mechanism matters because an attacker-controlled SSH key keeps repository access alive even after token revocation and password rotation.
• The limiting control is not just uninstalling the extension, but removing attacker-created credentials and governing IDE session reuse as part of identity security.

Key terms

• Shared Authentication Model: A shared authentication model lets one application reuse an already established identity session across extensions or components. In practice, that convenience becomes a governance problem when untrusted code can inherit a live credential path without separate approval or visibility into the resulting access scope.
• Credential Persistence: Credential persistence is the ability of an attacker to keep access after the original secret is revoked or the initial malware is removed. In identity terms, it usually means a second credential, key, or token has been added to the account lifecycle and now survives the first response action.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Expanded Trust Boundary: A broader set of inputs, contexts, and downstream actions that can influence a system’s behaviour. AI systems often create this boundary because unstructured language and external context can affect decisions in ways conventional APIs do not.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.