What breaks when a malicious VS Code extension can inherit a GitHub session silently?

Why This Matters for Security Teams

A malicious VS Code extension is not just a plugin risk. If it inherits an active GitHub session, it can act inside the developer’s trust boundary, create durable access, and bypass the normal assumptions behind token revocation. That is why this issue often becomes an account persistence problem rather than a single compromised token event. NHI Management Group’s analysis of the JetBrains GitHub plugin token exposure shows how developer tooling can extend identity exposure beyond the obvious login path.

The security failure is usually lateral: a session is inherited, then the extension uses that access to add SSH keys, authorize apps, or plant alternate credentials. Once that happens, uninstalling the extension or rotating the original OAuth token may not remove the attacker’s foothold. This is why controls focused only on secrets rotation miss the persistence mechanism. Current guidance from NIST SP 800-53 Rev. 5 Security and Privacy Controls remains relevant, but it must be applied to identity artifacts created after compromise, not only the initial session itself. In practice, many security teams discover the second credential path only after repo access continues despite password resets and extension removal.

How It Works in Practice

The attack works because browser-like or embedded sessions can be reused silently by extension code running in a trusted workstation context. A malicious extension may not need to steal a password at all. It can call GitHub APIs, interact with the developer profile, and establish a long-lived access path through SSH keys, PATs, or app authorizations. That is why the incident response question is not only “Was the token revoked?” but also “What new identity material was added?”

For defenders, the practical control set is identity-centric and event-driven:

• Review GitHub account security history for newly added SSH keys, OAuth grants, and GitHub App authorizations.
• Search for extension installation and update events on endpoints where the session was present.
• Revoke all active sessions, not just the suspected token, then force re-authentication.
• Check whether repository or org access was expanded through alternate credentials before closure.
• Correlate workstation telemetry with Git provider audit logs and developer IDE extension inventory.

This is consistent with the broader pattern seen in the Shai Hulud npm malware campaign and the Reviewdog GitHub Action supply chain attack, where trusted execution paths became credential-exposure paths. It also aligns with OWASP guidance on extension and supply chain abuse, where the extension boundary is often weaker than the account boundary it inherits. Where teams rely on a single token revocation workflow, this guidance breaks down in environments with persistent SSH key use, cached browser sessions, or unmanaged developer endpoints because alternate credentials survive the original remediation.

Common Variations and Edge Cases

Tighter session controls often increase developer friction, so organisations have to balance rapid response against workflow disruption. There is no universal standard for this yet, but current guidance suggests treating IDE extensions as privileged software when they can inherit authenticated sessions or access source-control tokens.

Some environments are more exposed than others. Cloud-hosted dev environments, shared workstations, and remote pair-programming tools can spread the session surface beyond one laptop. In those cases, the relevant question is whether the extension could reach GitHub through any shared browser state, device trust, or cached auth context. GitGuardian’s The State of Secrets Sprawl 2025 reports that 91.6% of secrets remain valid five days after notification, which shows how often remediation lags behind exposure.

• Extensions should be reviewed as part of software allowlisting, not only user preference management.
• SSH keys, deploy keys, and fine-grained tokens need separate revocation checks.
• Org-level policies should require audit visibility for new credentials created by user accounts.
• Where possible, use short-lived auth and device-bound controls instead of durable developer session reuse.

In practice, the highest-risk edge case is a developer account with broad repository rights and no enforced review of newly added SSH keys, because the attacker’s persistence survives the very cleanup steps teams usually trust.

Related resources from NHI Mgmt Group

• What breaks when a malicious IDE extension can read cloud credentials and environment variables?
• What should security teams do when a VS Code extension starts spawning script hosts?
• What breaks when malicious code can run inside a developer IDE or package install?
• What breaks when an IDE extension can fetch commands and execute them on startup?