Poisoned VS Code extensions expose the limits of auto-update trust

At a glance

What this is: Aikido describes how poisoned VS Code extensions can use default auto-update and stolen publisher credentials to push malicious code into developer machines within minutes.

Why it matters: IAM, PAM, and NHI teams should treat extension publishers and their tokens as high-risk software supply chain identities, because marketplace trust can become an uncontrolled delivery path.

Context

VS Code extension distribution is a trust problem as much as a software distribution problem. When an extension publisher token is stolen, auto-update can turn a trusted marketplace into a rapid malware delivery path, and the control gap is the absence of a delay, recall, and revocation layer between publish and install.

That matters to identity teams because the publisher token, the signed extension build, and the developer workstation all sit inside the same trust chain. Once a compromised release is published, conventional review and detection processes may already be behind the attacker, especially when update checks happen automatically in the background.

The article's examples are not edge cases; they show a repeatable weakness in extension governance. In practice, the starting position of many developer environments is typical, not exceptional, which is why marketplace trust now needs explicit policy control.

Key questions

Q: What breaks when VS Code extension auto-update is left fully trusted?

A: A compromised publisher can push malicious code straight into managed developer workstations before human review or security tooling has time to react. The failure is not just faster infection, but the collapse of the assumed gap between publish and install, which leaves no practical buffer for detection, rollback, or intervention.

Q: Why do stolen extension publisher tokens create such a large security risk?

A: Because the token is the identity that authorises software publication. If an attacker controls it, they can release a malicious version that still looks legitimate to the marketplace and reaches existing installs automatically. That turns a single compromised credential into a broad endpoint delivery path and expands the blast radius far beyond one repository.

Q: What are the signs that extension trust controls are too weak?

A: Look for immediate installs of new or updated extensions, access to secret-bearing local files from tooling that does not need them, and developer endpoints operating outside any device-side release policy. Those are signs that trust decisions are being made too late.

Q: How should organisations govern compromised extension publishers and endpoints?

A: They should treat the compromised publisher as a revoked non-human identity, block the affected versions, and rotate any secrets accessible from workstations that installed the release. The incident response scope has to include publisher credential review, endpoint containment, and credential replacement, not just marketplace takedown.

Technical breakdown

How poisoned extension releases reach clients so quickly

VS Code-based editors treat extension updates as a client-side sync problem. When the gallery reports a newer version, the editor can install it automatically with no user prompt, and the trigger may come from startup checks, idle checks, policy changes, or even unrelated gallery lookups. That means the installation path is not a slow release train but a near-immediate propagation channel once the marketplace accepts a malicious build. The security issue is not the existence of auto-update by itself, but the lack of a trust delay between publication and endpoint installation.

Practical implication: add a release-to-install cooldown for extension updates before they can reach managed endpoints.

Why stolen publisher tokens are enough to weaponise the marketplace

The attacker does not need to compromise the editor itself if they can authenticate as a legitimate publisher. A stolen GitHub token, a compromised repository secret, or another exposed publishing credential lets the attacker upload a malicious version that still looks trusted to the marketplace. Verified badges and high install counts then work against defenders, because they lower suspicion while the compromised release spreads. In NHI terms, the publisher token is the privileged non-human identity in the chain, and its compromise directly substitutes attacker intent for normal release authority.

Practical implication: govern publisher tokens as high-value NHIs with rotation, scoping, and revocation controls.

Why marketplaces cannot cleanly recall already installed malicious code

Once a malicious extension lands on a workstation, marketplace takedown only stops new installs. Existing clients need a clean replacement release, manual uninstallation, or separate endpoint action because the marketplace has no universal rollback mechanism for already installed copies. That creates a detection gap where the incident is already over for the attacker but not yet contained for the victim. If the compromised build existed long enough to be auto-updated onto endpoints, the cleanup problem shifts from the marketplace to device governance and secret revocation.

Practical implication: pair takedown response with forced secret rotation and endpoint review for every affected device.

Threat narrative

Attacker objective: The attacker aims to convert trusted extension distribution into a silent endpoint compromise channel for stealing developer credentials and reaching downstream systems.

1. Entry occurred when an attacker used a stolen publisher credential to upload a poisoned VS Code extension release to a trusted marketplace.
2. Credential abuse followed as the malicious build was accepted as legitimate publisher output and distributed through auto-update paths to developer machines.
3. Impact was the installation of malicious code on endpoints that could expose tokens, secrets, and SSH keys already reachable from the affected machine.

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

Auto-update has become an implicit trust grant, not just a convenience feature. When extension clients install new releases automatically, the marketplace becomes a live delivery path rather than a passive catalogue. That shifts the security question from whether a package is signed to whether the organisation is willing to accept immediate propagation from any trusted publisher. Practitioners should treat extension update timing as a control boundary, not a usability detail.

Publisher tokens are the real non-human identities in this attack chain. The article shows that once a publishing credential is stolen, the attacker inherits the authority to distribute code to millions of endpoints through a trusted channel. That is an NHI governance problem, not just a supply chain problem, because the credential itself is the privileged actor that authorises software publication. The practical conclusion is that publisher identity needs lifecycle control, not just secret storage.

Marketplace trust now needs a delay layer to match the speed of abuse. The central failure mode is not merely malicious code upload, but the absence of a controlled interval between release and install. That gap lets maintainers, EDR, and human review arrive after the payload is already on disk. The named concept here is extension trust latency: the unsafe time between publication and enforced policy evaluation. Practitioners should reduce that latency before attackers exploit it again.

Endpoint compromise from extensions is now a credential governance event. The moment a malicious extension runs on a developer machine, the likely blast radius includes tokens, secrets, SSH keys, and any credentials adjacent to the workspace. That means incident response has to start from identity exposure assumptions, not from the marketplace listing alone. Security teams should treat affected developer devices as credential-contamination zones until secrets are rotated and session paths are reviewed.

Allowlisting without a cooldown is incomplete control. The article makes clear that organisations can constrain publishers and versions, but still leave the install window too open if every approved update lands immediately. A useful governance model combines approved sources with minimum-age policy and rapid revocation for compromised publishers. Practitioners should close the timing gap, not just the source gap.

From our research library:

• Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe, according to the State of Secrets Sprawl 2026.

What this signals

Extension trust latency: the risky interval is no longer the time to patch, but the time between publication and enforced install policy. If that window is measured in minutes, attackers can reach developer endpoints before maintainers can react, which means release governance has to be treated like access governance.

The NHI angle is direct: publisher tokens behave like privileged identities, and once they are stolen the attacker inherits release authority across marketplaces. Security teams should assume extension distribution can become an identity-driven supply chain event, not just a software hygiene issue. The practical answer is delayed install policy, not blind confidence in auto-update.

For practitioners

• Delay extension installs by policy Introduce a minimum-age window between publication and installation so newly released extensions cannot auto-install immediately on managed devices.
• Treat publisher tokens as NHIs Inventory extension publishing credentials, scope them tightly, rotate them regularly, and revoke any token that may have been exposed or reused.
• Disable automatic extension updates for high-risk environments Use controlled update scheduling on developer endpoints where the risk of compromised marketplace releases outweighs the convenience of immediate patches.
• Rotate exposed secrets after suspicious extension activity Assume tokens, SSH keys, and other secrets reachable from affected workstations may already be compromised, then rotate and reissue them in priority order.
• Review marketplace allowlists and version constraints Restrict installs to approved publishers and specific version ranges so a compromised release cannot spread freely across the fleet.

Key takeaways

• Poisoned VS Code extensions turn trusted auto-update into a rapid delivery path, so release timing becomes a control problem rather than a convenience feature.
• The attack pattern depends on compromised publisher credentials, which function as privileged non-human identities for software publication.
• Defence has to combine install delay, publisher revocation, and secret rotation because takedown alone does not clean up already installed code.

Key terms

• Extension trust latency: The delay between publishing a software extension and the moment it is allowed to install on endpoints. In this context, shorter latency increases exposure because a malicious or compromised release can reach users before people or tools can intervene.
• Publisher Token: A publisher token is a secret that authorises package publication or version changes in a registry. In practice it functions like distribution authority, because anyone who holds it can turn a trusted package into a delivery mechanism for malicious code.
• Auto-update trust: The assumption that newly published software should be installed automatically without explicit human review. It is useful for patching, but dangerous when publication authority can be compromised, because trust in the release process becomes trust in the attacker.
• Release Cooldown: A time delay applied before a newly published package or update can be adopted by automated systems. It reduces the chance that poisoned releases move immediately into production and gives defenders time to detect, validate, and block suspicious changes.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is designed for practitioners who need to govern privileged identities, secret sprawl, and the controls around them.