Revoking Your Token Won't Save You: The VS Code Attack That Installs a Permanent GitHub Backdoor

The Attack That Survives Your Response

When a developer discovers a compromised VS Code extension, the playbook is straightforward: uninstall the extension, revoke the OAuth token, rotate your passwords. Done.

Except it isn't.  At least, not anymore.

Knostic's security research team has identified malicious VS Code extensions abusing VS Code's shared GitHub authentication model, distinguished by a persistence mechanism that survives standard incident response. These extensions are designed not just to steal your credentials, but to plant a backdoor into your GitHub account that survives token revocation, password rotation, and even uninstalling the extension itself. By the time you realize something is wrong, the attacker may already have established persistent Git access to every repository you own... and revoking your token does nothing to stop them.

Here's how it works, what we found in the wild, and, critically, what you need to check right now even if you've never heard of these extensions.

The Vulnerability: Silent OAuth Session Hijacking

VS Code has a built-in authentication system that lets extensions request access to your GitHub account. When you install GitHub Copilot or the GitHub Pull Requests extension, VS Code stores a GitHub OAuth session locally. Any other extension can then silently request access to that same session, with no visible prompt to the user, using a single API call:

vscode.authentication.getSession('github',['read:user','user:email','repo','workflow'],{silent:true})

If you have any GitHub extension already installed, this call may succeed, returning a live OAuth token with the broadest possible scopes — without you ever seeing a dialog box. The token grants full read and write access to all your repositories, including private ones.

This is not a bug in a single extension. It's a design characteristic of VS Code's shared authentication model, and it means that any extension you install can silently inherit your GitHub credentials.

Separately, security researcher Ammar Askar publicly disclosed a related attack in June 2026, a one-click technique abusing VS Code's webview message-passing to extract tokens from github.dev. While that technique differs from the silent session hijacking used here, both abuse VS Code's shared GitHub authentication model through different mechanisms.

If the silent call fails (no existing GitHub session), the extension falls back to showing an OAuth consent dialog requesting only the repo scope — the minimum needed to access all private repositories. The prompt appears to come from VS Code itself, not from the malicious extension.

What We Found in the Wild

While conducting routine threat hunting across the VS Code and OpenVSX marketplaces, Knostic researchers identified two extensions exploiting this technique. Both were discovered through AgentMesh, Knostic's supply chain security platform for AI development tooling.

Both extensions were analyzed via static code review. Neither accumulated installs before removal, and no victim activity has been confirmed. The behaviors described in this post reflect each extension's designed functionality as observed in source code.

That said, the infrastructure built by theme-helper-utils in particular, server-side SSH keypair generation, a dedicated exfiltration endpoint, evasion against extension-listing diagnostics, reveals operational sophistication that goes well beyond a proof of concept.

Inside the Attack: A Step-by-Step Walkthrough

Static analysis of theme-helper-utils (SHA256: 62218ea17ee9f369ef16b16fb07856e7b2729b259a55991f3b4047785f702950) revealed the following attack chain, executed entirely on onStartupFinished — meaning it runs automatically every time VS Code opens, with no user interaction required.

The Part That Makes This Different: SSH Persistence

OAuth token theft from VS Code extensions is a known risk. What sets this attack apart — and what makes standard incident response insufficient — is step 4: the SSH key implantation.

The diagram below shows why revoking your token closes only half the door.

The attack uses a two-phase approach that appears uncommon in publicly documented VS Code extension malware and represents a notable evolution in persistence tradecraft:

1. The extension sends the victim's GitHub username to the attacker's server, which generates an SSH keypair server-side and returns only the public key
2. The extension is designed to plant that public key on the victim's GitHub account via the GitHub API, titled vscode-recovery

The attacker retains the private key. This means:

Revoke your OAuth token → attacker still has git access via SSH

Rotate your password → attacker still has git access via SSH

Uninstall the extension → attacker still has git access via SSH

The only action that terminates access is explicitly removing the vscode-recovery SSH key from your GitHub account settings.

This persistence mechanism is deliberately designed to survive the standard response. A developer who discovers the compromise, revokes their token, and considers the incident closed is still fully exposed.

What Was Exfiltrated

The .env exfiltration is worth emphasizing. In a typical developer environment, .env files contain database credentials, third-party API keys, cloud provider secrets, and internal service tokens. The attack is designed to systematically collect these from the 15 most recently active repositories — not just the current workspace.

Who Is at Risk

Any VS Code or Cursor user may be a viable target if they have:

• GitHub Copilot installed, or
• The GitHub Pull Requests and Issues extension installed, or
• Any other extension that has established a GitHub OAuth session

No additional user action is required. Simply having one of these extensions installed means a malicious extension can silently inherit your GitHub credentials the moment VS Code starts.

Given that GitHub Copilot has tens of millions of users, the potential victim pool for this attack class is very large.

Indicators of Compromise

All domains and URLs below are defanged. Replace [.] with . and hxxps[://] with https:// to reconstruct live values.

theme-helper-utils (pemhkakbh) — AgentMesh report

GHDev Token Steal PoC (julesgzel) — AgentMesh report

Behavioral Indicators

• VS Code extension making POST /user/keys calls to api.github.com
• Extension calling vscode.authentication.getSession with silent: true on onStartupFinished
• Network traffic to Cloudflare Workers domains at VS Code startup
• SSH key titled vscode-recovery appearing in GitHub account
• SSH key with comment implant@poc appearing in GitHub account or ~/.ssh/authorized_keys

C2 Infrastructure Validation

During the review process, Knostic researchers validated the behavior of the C2 infrastructure associated with theme-helper-utils. A request to the root of github-token-poc[.]app-kvil11[.]workers[.]dev returned {"status":"live"}, and the /keygen endpoint was functional, generating valid ssh-ed25519 public keys on request. This confirms the infrastructure was not placeholder or abandoned: the full attack chain was ready to execute against any victim who installed the extension.

Multiple requests to /keygen produced distinct keypairs, consistent with the static analysis finding that each victim receives a unique SSH key. All generated keys carried the comment implant@poc, added to the IOC table above. One consequence of per-victim key uniqueness is that there is no reusable public-key fingerprint to hunt across GitHub accounts, each planted key is different, leaving the SSH key title (vscode-recovery) and comment (implant@poc) as the only consistent artifacts. Neither the extension's file hash nor the C2 domain appeared in VirusTotal or any public threat intelligence feed at the time of investigation.

Remediation

If you have installed any untrusted VS Code extension recently, particularly one published by a random-string publisher account with zero reviews, take these steps in order:

1. Check SSH keys first. Go to GitHub Settings → SSH and GPG Keys. Look for any key titled vscode-recovery or carrying the comment implant@poc that you did not add yourself. If you find one, remove it immediately and treat all credentials in your repositories as compromised.
2. Revoke the OAuth token. GitHub Settings → Applications → Authorized OAuth Apps
3. Rotate all .env secrets. Treat every .env and .env.local file in your active repositories as compromised
4. Rotate GitHub Actions secrets. The attacker received the names of all your CI/CD secrets; rotate anything sensitive
5. Notify your organization. If your GitHub account has organization memberships, your security team needs to know
6. Audit installed extensions. Remove any extension published by a random-string or newly created publisher account with no installs or reviews

Note: Steps 2–6 are irrelevant if you haven't completed step 1. Revoking the OAuth token alone does not terminate attacker access.

The Broader Pattern

These two extensions represent the beginning of a trend, not an isolated incident. The VS Code extension marketplace processes a high volume of new submissions daily, and the authentication model that enables this attack class is a platform-wide characteristic, not something individual extensions can opt out of.

Knostic's AgentMesh platform monitors the VS Code and OpenVSX marketplaces continuously for extensions exhibiting this behavior. During ongoing marketplace monitoring, we continue to identify newly published extensions exhibiting behavioral and publication patterns that warrant further investigation.

The most effective defense at the individual level is simple: treat VS Code extensions with the same scrutiny you apply to any software you install. Check the publisher, check the install count, check the reviews. A syntax theme with zero installs, published yesterday by an eight-character random string account, should raise the same flags as an unsigned binary from an unknown source.

We will continue publishing findings as we identify them.