Open VSX extension abuse is turning developer workstations into footholds

At a glance

What this is: This is a Pluto Security analysis of EtherDuck, a malware campaign that abused fake Solidity extensions, marketplace ranking manipulation, and hidden payloads to persist on developer systems across Windows, macOS, and Linux.

Why it matters: It matters because developer workstations often hold source, cloud, CI/CD, and wallet access, so a compromised extension can become an organisation-wide identity and infrastructure problem, not just an endpoint issue.

Context

Developer workstation compromise is a governance problem when the workstation is also the control point for code, cloud access, and deployment authority. In this case, the primary issue is not just malware delivery, but trust in extension marketplaces and the identity of the publisher behind the package.

EtherDuck shows how attackers can turn a routine tooling decision into persistent access across development environments. The article’s central risk is the collapse of normal marketplace trust when the malicious package looks like a legitimate developer dependency.

Key questions

Q: What breaks when malicious extensions or packages are trusted inside developer toolchains?

A: The trust boundary breaks because the tool can stay functional while quietly reading source code, credentials, or session material. That means detection based on user complaints or obvious failure is too late. Organisations need approval, runtime monitoring, and scoped access before the tool reaches a developer workstation.

Q: Why do compromised developer workstations create broader risk than a normal endpoint compromise?

A: Because the workstation usually holds access to source control, build systems, cloud consoles, and deployment credentials. A compromise there can alter code, poison builds, publish packages, or trigger malicious infrastructure changes. The blast radius extends far beyond the local machine, so containment has to include downstream identity and pipeline access.

Q: What signs suggest an extension-based compromise has moved into persistence?

A: Look for new startup entries, launch agents, user-level services, hidden helper processes, and unexpected remote-access components created around the time of installation. If those artefacts appear after a developer extension is added, the compromise is no longer just at install time. It has become an operational foothold.

Q: How should teams decide whether to trust an extension marketplace listing?

A: Use the listing as a starting point only. Compare the publisher account with the genuine project owner, check whether the repository is linked and active, and validate whether the extension’s behaviour matches its declared purpose. A high download count without provenance is a weak trust signal, not a strong one.

Technical breakdown

How fake extension listings win developer trust

The first stage is social and marketplace-based rather than technical. Attackers impersonate trusted developer tooling, copy the display name of a legitimate extension, and inflate download counts so the malicious listing looks more credible in search results. That matters because extension marketplaces become identity systems of their own: the publisher account, listing metadata, and install signal are effectively the authentication layer for trust. Once a developer installs the package, the actor has a path to execute code in the workstation context, which is the real prize. See the Browser Extension Security Guide.

Practical implication: Treat marketplace reputation, publisher identity, and install telemetry as security controls, not convenience signals.

How the hidden payload survives basic inspection

EtherDuck does not rely on a plainly malicious executable. The extension contains a large video file that acts as a carrier for an appended archive, and the code launches a hidden process at startup to unpack and execute it. The payload is split across format layers and checked with hashes before extraction, which defeats simple file inspection and signature-based scanning. This is a classic packing and staging pattern: the visible artefact is benign enough to pass a casual review, while the runtime behaviour is where the compromise actually happens.

Practical implication: Inspect extension runtime behaviour and extracted artefacts, not just the packaged files visible at install time.

How cross-platform persistence and blockchain C2 extend dwell time

The campaign uses separate payloads for Windows, macOS, and Linux, then persists through startup hooks, services, or launch agents depending on platform. On macOS and Linux, the malware avoids a conventional hardcoded C2 by reading configuration from an Ethereum smart contract, which gives the operator a durable address book that can be changed without republishing the malware. That architecture shifts the defender’s problem from removing a single file to tracing a distributed control plane. It also means the compromise can survive infrastructure churn and reappear under a different publisher identity. See the macOS Detection and Response Guide.

Practical implication: Monitor for persistence mechanisms and blockchain-based configuration retrieval, not only for known malicious domains.

Threat narrative

Attacker objective: The operator wants durable access to developer workstations so it can steal credentials, manipulate code and builds, and preserve a reusable control channel into software delivery environments.

1. Entry begins when developers install a fake Solidity extension that impersonates trusted tooling and is boosted by inflated download counts in marketplace search.
2. Credential access follows once the payload executes on the workstation and gains persistent access to the developer environment, where it can reach source control, cloud sessions, wallet material, and deployment secrets.
3. Escalation occurs through platform-specific loaders and persistence paths that install remote-access tooling or a backdoor across Windows, macOS, and Linux.
4. Impact is organisation-wide compromise of developer trust, code integrity, and downstream deployment authority, with the operator able to return under new publisher identities after takedown.

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.
• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

Marketplace trust is now part of the workstation attack surface: extension stores are no longer just software distribution channels, they are identity decision points. When publisher identity, download counts, and search ranking can all be manipulated, the trust model behind developer tooling collapses into an adversary-controlled signal chain. Practitioners should treat marketplace provenance as a governance control, not a user convenience.

Developer workstations are high-value identity assets, not ordinary endpoints: the article shows how one successful installation can expose source control, cloud CLI sessions, deployment keys, and wallet material in the same compromise. That makes the workstation a junction point for human identity, NHI, and build-time authority. Security teams need to evaluate compromise at the level of downstream access paths, not just local infection.

Extension abuse has become a supply-chain style persistence problem: takedown of the listing does not remove the payload from devices or break the operator’s access path. The campaign’s reuse of the same payloads under new publisher identities shows that defenders are fighting an operational model, not a single malicious package. The implication is that response has to cluster related artefacts and accounts, not just delete one listing.

Cross-platform payloads increase governance failure, not just reach: one campaign now spans Windows, macOS, and Linux with separate persistence mechanisms and the same underlying operator. That broadens exposure across mixed developer fleets and complicates inventory, detection, and offboarding of compromised tooling. Practitioners should assume the attacker will choose the platform that best matches the victim’s workflow, then persist through whichever control layer is weakest.

Identity blast radius is the right concept for this class of compromise: once the extension lands, the real security question is how far the workstation’s trusted identity can propagate into Git, CI/CD, cloud consoles, and package registries. That blast radius is what turns a single install into an organisation-wide event. A mature programme limits the reach of any one developer context before the next credential is touched.

What this signals

Identity provenance will matter more than package popularity: development teams should expect attackers to keep abusing store rankings, publisher impersonation, and lookalike naming because those signals are easy to game. The practical shift is toward validating who published the tool, how it was built, and what it can reach once installed.

Developer security programmes will need to treat extensions as part of the access layer, not just the software supply chain. When a package can reach source, cloud, and deployment credentials from a single workstation, the control boundary is the identity context attached to that machine, not the package alone.

For practitioners

• Tighten extension allowlisting Approve developer extensions by publisher, repository history, and package hash rather than by display name or install count alone.
• Inventory workstation-held secrets Assume any developer machine that executed the payload may have exposed cloud CLI sessions, SSH keys, wallet material, and deployment secrets.
• Hunt for platform-specific persistence Look for startup entries, launch agents, systemd user services, and remote-access services created after extension installation.
• Block on network and contract indicators Search for outbound traffic to the relay and backdoor addresses, plus repeated contract reads from developer workstations that should not normally query Ethereum configuration data.
• Rebuild trust in extension intake Require linked source repositories, verified publisher history, and central review for any extension that can reach sensitive development or deployment systems.

Key takeaways

• A fake extension can become a durable entry point into source control, cloud sessions, and deployment authority when developer trust is based on marketplace signals alone.
• The campaign is notable for cross-platform persistence, hidden payload staging, and the ability to return under new publisher identities after takedown.
• Practitioners should respond by tightening extension provenance checks, hunting for workstation persistence, and treating developer endpoints as high-value identity assets.

Related NHI Mgmt Group resources: Browser Extension Security Guide · Secrets Management Buyer's Guide · macOS Detection and Response Guide · Malware Guide

Key terms

• Developer Workstation: A developer workstation is the endpoint where engineers build software, run command-line tools, and access source code, cloud services, and secret stores. In practice, it becomes a high-value identity target because many privileged credentials coexist there, making one compromised machine a launch point for repository, infrastructure, and supply chain abuse.
• Marketplace Provenance: Marketplace provenance is the origin trail for a plugin or extension, showing where it was installed from and how it entered the environment. It helps security teams judge trust, assess supply chain risk, and distinguish official sources from community or repository-based installs that may behave differently over time.
• Persistence: Persistence is the ability to retain memory, state, or goals across sessions and time. In NHI governance, persistence matters because retained context can influence later access decisions, create hidden privilege, and extend the impact of a prior task beyond its intended window.
• Extension Takedown: Extension takedown is the removal of a malicious or abusive package from a marketplace. It limits new installs, but it does not automatically remove code already executed on endpoints or break any access the attacker has already established.

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.