VS Code extension persistence breaks standard GitHub token response

At a glance

What this is: This is a research-driven analysis of malicious VS Code extensions that abuse shared GitHub authentication and add SSH-based persistence to survive normal response steps.

Why it matters: It matters because identity and access teams must treat developer tooling as an identity surface, not just an endpoint risk, and revocation alone may not end repository exposure.

By the numbers:

• The malicious extension used an 800ms startup delay to avoid scanners that flag immediate network activity at launch.

👉 Read Knostic's analysis of VS Code extension hijacking and GitHub token persistence

Context

VS Code extensions can become an identity problem when they inherit an existing GitHub OAuth session and reuse it without a separate user decision. In this case, the risk is not just token theft. It is persistent account access that survives the response steps many teams assume are sufficient.

For IAM and NHI practitioners, the important question is whether a developer tool can create its own durable access path after the original credential is revoked. If it can, then the access review, secret rotation, and incident response model are all working from an outdated assumption about what actually closes the door.

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 do VS Code extension attacks create more risk than simple token theft?

A: Because they can turn a transient session into durable repository access. The risk is not only exfiltration of the current token, but also enumeration of repos, collection of .env material, and persistent SSH-based access that survives the normal response sequence. That changes the incident from credential loss to identity lifecycle failure.

Q: How do security teams know if a developer identity has been re-bound after revocation?

A: Check for newly added SSH keys, unexpected OAuth authorizations, unusual repository access patterns, and any extension activity tied to startup events. If the account can still authenticate through an alternate path, the revocation did not actually remove access. The account must be treated as compromised until all credentials are accounted for.

Q: Who is accountable when a developer tool plants persistent repository access?

A: The accountability sits with the identity and platform owners who govern GitHub sessions, SSH keys, and approved tooling, not only with the endpoint team. This is a shared control problem across IAM, developer experience, and incident response. The governing question is whether the organisation can prove that the planted credential was removed.

Technical breakdown

Shared GitHub authentication in VS Code

VS Code supports shared GitHub authentication so extensions can request access to an already established session. The abuse path is simple: a malicious extension calls vscode.authentication.getSession with silent set to true, and if a GitHub session exists, it can receive a live token without prompting the user. That token can carry broad repository scopes, which means the extension is not limited to its own runtime context. This is an identity delegation problem, not just a malware problem, because one trusted session becomes a reusable credential source for untrusted code.

Practical implication: treat extension access to GitHub as a credentialed trust boundary and review which extensions can inherit existing sessions.

SSH key implantation as persistence

The persistence mechanism is what makes this attack materially different from simple OAuth theft. After obtaining the token, the extension can call the GitHub API to add an attacker-controlled SSH key to the victim account. That key becomes an alternate authentication path, independent of the original OAuth token and independent of the extension remaining installed. This creates a second, durable identity artifact in the account itself. Revocation of one credential does not matter if another credential has already been planted through the same trusted session.

Practical implication: investigate GitHub account SSH keys as part of incident response, not just OAuth app authorizations.

Startup-time execution and stealth controls

The code executes on onStartupFinished, which means the malicious logic runs automatically each time VS Code opens. It also uses evasion techniques such as delaying startup activity and patching JSON.stringify so diagnostics and telemetry can miss the extension's true identity. After that, it performs account enumeration, repository scanning, and exfiltration of .env contents, secret names, and workflow definitions. The attack chain is built for persistence and discovery, not one-off theft, which increases the blast radius across repositories and CI/CD material.

Practical implication: monitor extension startup behaviour and outbound calls to identity and exfiltration endpoints, especially where repository secrets are exposed.

Threat narrative

Attacker objective: The attacker wants durable GitHub repository access that survives normal response actions and supports secret collection across active developer repos.

1. Entry occurs when a malicious VS Code extension inherits an existing GitHub OAuth session through shared authentication and requests access silently on startup.
2. Escalation occurs when the extension plants an attacker-controlled SSH key on the GitHub account, creating a second authentication path that survives token revocation and uninstall.
3. Impact occurs when the attacker uses persistent git access to enumerate repositories, collect .env contents and workflow material, and maintain continued repository control.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• JetBrains GitHub plugin token exposure — CVE-2024-37051 in JetBrains IntelliJ GitHub plugin exposed GitHub access tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shared developer-tool authentication is now an identity governance problem, not a browser-session convenience. VS Code's model assumes that inherited GitHub sessions remain safe when reused by extensions. That assumption fails when untrusted code can silently request scopes and then convert that access into a durable authentication path. The implication is that extension trust, not just account hygiene, has to sit inside the identity control model.

Persistent GitHub access outlives the token when SSH key injection is possible. This attack worked because revocation was only half a response. Once an attacker adds a new SSH key, the original OAuth session becomes irrelevant to the persistence decision. The control gap is not token rotation failure, but lifecycle blindness to alternate credentials created through delegated access.

Ephemeral token trust debt: the attack shows that access reviewers often inspect the original token, while the real risk is a planted credential that was never part of the review scope. That breaks the common assumption that revoking the initiating session closes the identity path. Practitioners must treat account-level credential surfaces as a single governance object, not separate admin chores.

Developer tooling is becoming a privileged identity broker. A code editor extension that can reach GitHub, enumerate repositories, and read workflow material is functionally operating inside the identity perimeter. That means NHI-style governance principles now apply to parts of the developer stack that used to be treated as productivity software. The practitioner conclusion is clear: access inheritance needs lifecycle controls, not just endpoint controls.

OWASP NHI Top 10 thinking applies directly here because the abuse path combines credential exposure, privilege reuse, and persistence. The attack pattern maps to the same governance failures seen in NHI incidents: standing access that is broader than expected, hidden credential reuse, and poor visibility into where secrets can be reconstituted. Security teams should evaluate extension ecosystems through the same lens they use for service accounts and API keys.

From our research:

• GitHub Copilot has tens of millions of users, creating a very large potential victim pool for this attack class, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to The State of Secrets in AppSec.
• Read the Secret Sprawl Challenge for a practical view of how exposed secrets compound identity risk across development workflows.

What this signals

Ephemeral credential trust debt: developer tools that inherit authenticated sessions create a hidden governance burden because revocation no longer guarantees closure. The programme implication is that identity teams must track alternate credentials and account-level persistence, not just the original token or app authorization.

With 43% of security professionals worried that AI systems will learn and reproduce sensitive code patterns, per The State of Secrets in AppSec, secret handling in developer tooling now affects both leakage and identity re-binding risk.

The next control gap is not simply extension vetting. It is whether GitHub, IDEs, and CI/CD systems are governed as one identity surface, with visible ownership for OAuth sessions, SSH keys, and secret rotation outcomes.

For practitioners

• Audit GitHub SSH keys immediately Search for keys titled vscode-recovery or carrying the comment implant@poc, then remove any key you did not intentionally create. Check both the GitHub account settings and any local authorized_keys artefacts that could indicate mirrored persistence.
• Review extension inheritance of GitHub sessions Inventory which VS Code and Cursor extensions can call shared authentication APIs and inherit existing GitHub sessions. Remove or restrict untrusted extensions, especially those with random-string publishers or zero-install provenance.
• Rotate repository secrets after account-level compromise Treat .env files, cloud credentials, API keys, and workflow secrets in active repositories as exposed if the account was targeted. Rotate downstream secrets in the order of blast radius, starting with production credentials and CI/CD material.
• Add GitHub account telemetry to incident response Monitor OAuth app authorizations, SSH key additions, and unusual repository enumeration as part of developer account response. A token revocation event should trigger a second check for alternate authentication paths before the incident is declared closed.
• Apply zero standing privilege thinking to developer tools Limit which extensions can inherit authenticated sessions and require explicit review before any tool can access repository scopes. Where possible, separate productivity tooling from identities that carry write access to private repositories.

Key takeaways

• This attack succeeds because shared developer-tool authentication can be converted into persistent GitHub access after the original session is revoked.
• The evidence points to a broader blast radius than token theft alone, because repository enumeration, secret discovery, and SSH key planting all occur in the same chain.
• Incident response must check for alternate credentials in the account, not only revoke the token, if it is going to actually end access.

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 Surface: The identity surface is the collection of systems where authentication, authorisation, and credential lifecycle decisions are made. For this article, it includes the editor, GitHub sessions, SSH keys, OAuth app grants, and any workflow or repository secret that can extend account access.
• Alternate Authentication Path: An alternate authentication path is any credential or trust relationship that can be used after the primary token is removed. Security teams miss these paths when they treat revocation as the end of the incident instead of checking for newly planted keys, app grants, or delegated sessions.

What's in the full article

Knostic's full research covers the operational detail this post intentionally leaves for the source:

• Static analysis of the malicious extension code path, including the exact startup sequence and API calls used to inherit GitHub access
• The full indicator set for both malicious extensions, including hashes, endpoints, titles, and behavioural indicators
• A step-by-step remediation sequence for account owners who need to verify SSH keys, OAuth apps, and repository exposure
• The broader monitoring patterns used in marketplace threat hunting across VS Code and OpenVSX

👉 The full Knostic post covers the attack chain, persistence mechanism, and indicators of compromise

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.