Compromised IDE extensions turn developer tools into attack paths

At a glance

What this is: This analysis shows how malicious IDE extensions can turn developer tools into an attack path by running code, stealing credentials, and propagating compromise.

Why it matters: It matters because developer workstations, coding assistants, and extension ecosystems now sit close to code, tokens, and infrastructure, so IAM and NHI controls must cover the development toolchain.

Context

Compromised IDE extensions are malicious add-ons for development tools that can execute code, contact external services, and reach sensitive local assets. In identity terms, they sit close to non-human credentials because developer environments often hold tokens, API keys, and privileged access to repositories and deployment systems.

The governance gap is that many teams still treat the IDE as a productivity layer rather than a security boundary. Once extensions can load payloads, harvest secrets, or persist through updates, the development toolchain becomes part of the attack surface, and machine identity exposure follows quickly.

That makes this a developer-tool security problem with direct NHI implications. The article's examples are not edge cases; they reflect a recurring pattern where extension trust, code execution, and credential proximity combine into a supply chain risk.

Key questions

Q: What breaks when a malicious IDE extension is allowed to access developer tokens?

A: The trust boundary breaks because the extension can inherit the developer’s delegated access and turn local convenience into persistent cloud reach. Refresh tokens, environment variables, and browser-assisted login flows become credentials the attacker can reuse outside the user session. That is why extension approval must be tied to credential exposure, not just editor functionality.

Q: Why do compromised extensions create supply chain risk as well as endpoint risk?

A: Because they can access the same credentials used to commit code, trigger builds, or publish packages. If a malicious extension reaches those identities, the attacker can move from one workstation into shared software delivery systems and spread compromise through trusted channels.

Q: What are the warning signs that an IDE extension is behaving maliciously?

A: Look for eval(), encoded or obfuscated strings, unexplained file creation, remote downloads, and activation events that do not match the extension's stated purpose. A theme or helper extension should not need to fetch, decode, and execute payloads to do its job.

Q: How should organisations govern extension trust in development environments?

A: Treat extension approval as a lifecycle decision, not a one-time install choice. Verify publishers, inspect updates from dormant projects, isolate untrusted code first, and monitor developer workstations for access to secrets that could feed broader compromise.

Technical breakdown

How malicious VS Code extensions hide execution paths

A compromised extension often looks ordinary at install time but behaves like a loader once activated. Signals include eval(), encoded strings, heavy obfuscation, unexplained file creation, and network fetches that pull a second stage from elsewhere. In a VSIX package, package.json defines commands, activation events, and permissions, so unexpected triggers or remote calls are the first place to look. The technical risk is not just malicious code, but code that blends into routine extension lifecycle behaviour and inherits trust from the IDE. Practical implication: inspect extension manifests and JavaScript for activation abuse and remote execution hooks before allowing broad use.

Practical implication: Inspect extension manifests and JavaScript for activation abuse and remote execution hooks before allowing broad use.

Why developer workstations become credential targets

Developer workstations concentrate high-value secrets because they authenticate to source control, CI/CD systems, cloud services, and internal APIs. Once an extension runs in that context, it can read environment variables, browser sessions, local config files, and token stores without needing a separate privilege escalation step. That makes the endpoint itself a credential collection point rather than just a user device. The issue is not limited to stolen passwords; the real prize is the non-human identity material that underpins deployment and software delivery. Practical implication: treat developer endpoints as credential-bearing systems and monitor them for secret access patterns, not just malware signatures.

Practical implication: Treat developer endpoints as credential-bearing systems and monitor them for secret access patterns, not just malware signatures.

How supply chain feedback turns a local infection into wider impact

When a malicious extension can push code into repositories, CI jobs, or package registries, it creates a feedback loop that extends beyond the original machine. The compromise moves from endpoint malware to supply chain abuse because trusted development tooling is used to distribute the attacker’s payload or harvest additional credentials. That is why extension compromise matters to both code integrity and identity governance: the same trust relationship that allows productivity also allows propagation. Practical implication: assess which developer tools can write to shared code paths or publishing workflows and constrain those identities tightly.

Practical implication: Assess which developer tools can write to shared code paths or publishing workflows and constrain those identities tightly.

Threat narrative

Attacker objective: The objective is to turn trusted development tooling into a credential-harvesting and propagation channel that expands access across the software delivery chain.

1. Entry occurs when a developer installs a compromised IDE extension that appears legitimate but contains malicious activation logic or a hidden loader.
2. Credential access follows when the extension runs in the IDE context and reaches tokens, environment variables, local config files, or session material stored on the workstation.
3. Escalation happens when the stolen credentials or extension-driven code execution are used to access source control, CI/CD, or package publishing workflows.
4. Impact comes when the attacker uses those trusted development paths to spread malware, compromise repositories, or feed the infection back into the software supply chain.

Breaches seen in the wild

• Secrets in VS Code extensions 2025: Wiz found 550+ secrets in VS Code extensions, including publishing tokens able to push malicious updates to about 150,000 installs.
• GlassWorm campaign 2025: GlassWorm hid in VS Code extensions with invisible Unicode and stole npm, GitHub and Open VSX publishing tokens to spread.

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

Developer tools are now identity-bearing attack surfaces: The security model that treats an IDE as a benign productivity app no longer holds once extensions can execute code and reach high-value credentials. In practice, the extension ecosystem becomes part of the identity plane because it sits inside the workflow that handles source control, build access, and deployment authority. Practitioners should govern the IDE like any other privileged runtime.

Secret exposure inside extensions is a supply chain problem, not just an endpoint problem: A malicious extension does not need to break encryption or defeat MFA if it can read the tokens already present on the workstation. That means the governance failure is the assumption that developer secrets only need protection at rest or in the vault. Once secrets are locally reachable, the blast radius includes repositories, registries, and CI/CD.

Extension trust is a lifecycle issue that many programmes under-model: Publisher verification at install time is necessary but insufficient because risk can change when a long-dormant project updates, changes maintainers, or adds new behaviour. This is a classic lifecycle blind spot for NHI and software-delivery governance. The practical conclusion is that trust must be reassessed across extension updates, not frozen at initial approval.

Identity blast radius is the right named concept for this pattern: IDE compromise is dangerous because one trusted developer tool can expose multiple identity layers at once, from human sessions to workload secrets to publishing credentials. That means the blast radius is not limited to the endpoint that first executes the payload. Security teams need to treat every extension with write access as a potential propagation node.

OWASP-NHI and software supply chain controls intersect here: The article is really about non-human credentials being reachable from an environment that software teams assume is low risk. That makes offboarding, secret leakage, overprivilege, and supply chain integrity part of the same governance conversation. Teams that separate endpoint security from identity governance will miss the path by which compromise spreads.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: Secrets Management Buyer's Guide

What this signals

Identity blast radius is the key operational lesson: developer tooling can expose human sessions, machine tokens, and publishing credentials in one compromise, so access governance must extend into the IDE. The control point shifts from the perimeter of the workstation to the point where secrets are reachable.

Teams should also expect extension review to become part of software supply chain governance, especially where code editors can write to repositories or package registries. If a tool can move from local execution to shared publishing paths, the trust model has already widened beyond endpoint security.

The article reinforces a broader pattern that organisations still under-estimate: credential-bearing developer tools are not neutral utilities. When those tools can run third-party code, the safest assumption is that every extension update can change the identity risk profile.

For practitioners

• Restrict extension installation to verified publishers Allow only extensions from publishers you have explicitly approved, and review any extension that requests network access, command execution, or unusual activation events before broad deployment.
• Inspect extension manifests before approval Check package.json for activation events, remote fetches, command hooks, and permissions that do not match the extension's stated purpose.
• Monitor developer endpoints for secret access Alert on local reads of token stores, environment variables, and configuration files that contain API keys, publishing tokens, or session material.
• Isolate untrusted code execution Run untrusted extensions and new versions in isolated environments first, then promote them only after they show normal network and file behaviour.
• Revalidate dormant extensions after updates Reassess long-inactive projects when they release a new version, because a quiet extension can become a delivery path once its behaviour changes.

Key takeaways

• Compromised IDE extensions turn a development convenience into a credential-bearing attack surface that can reach code, tokens, and deployment paths.
• The compromise matters beyond the endpoint because extension access can feed directly into repositories, package registries, and other trusted software delivery systems.
• Teams should govern extensions as lifecycle-managed software, with publisher verification, update review, isolation, and secret monitoring as part of normal control design.

Key terms

• Compromised IDE Extension: A compromised IDE extension is a malicious or tampered add-on that runs inside a developer tool and uses that trust to execute code, collect data, or reach nearby credentials. In practice, it turns a productivity feature into a software-delivery risk and a non-human identity exposure point.
• 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.
• Extension Lifecycle Governance: Extension lifecycle governance is the practice of managing publisher trust, version changes, update cadence, and revocation for IDE or marketplace packages. It treats the extension as an identity-bearing object whose behaviour must be revalidated across its entire lifespan, not only at initial approval.
• Developer Secrets Exposure: The risk that workstations and CI hosts used for building software contain reusable credentials such as SSH keys, cloud tokens, registry secrets, or signing material. In supply-chain attacks, these secrets often become the primary target because they unlock later access beyond the initial host.

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.