77 Open VSX Extensions Were Harvesting Developer Data — The IDE Supply Chain Is Now the Weakest Link

August 4, 2026. Manifold Security published the findings of a campaign involving 77 malicious extensions on the Open VSX marketplace — the open registry for VS Code-compatible editors (VSCodium, Eclipse Theia, Gitpod, Code OSS). Dubbed the “evil twin” operation, it ran from July 26 through August 1, 2026 — a week during which thousands of developers may have unwittingly run reconnaissance code inside their own workspaces.

The numbers tell the scale: 58 extensions sent back basic system fingerprinting data; 19 extensions went much deeper, exfiltrating Git repository metadata, CI environment variables, and local project paths. A single exfiltration domain — discovered by correlating network traffic across all 77 extensions — linked the entire operation to one actor.

The Playbook: Evil Twins Impersonating Trusted Tools

The attackers didn’t build extensions from scratch. They cloned popular legitimate extensions — evil twins — replicating their names, descriptions, and metadata. A developer searching for “Prettier,” “ESLint,” or “GitLens” on Open VSX could land on a malicious copy without any obvious tell.

The malicious payload was embedded in each extension’s post-install script — a hook that fires automatically after installation, with no user interaction required. No suspicious dialog box. No permission prompt. The extension installs, the script executes, the data leaves the machine.

What sets this campaign apart from prior typosquatting attacks on npm or PyPI is the target. IDE extensions have access to the full development environment: the local filesystem, cloned Git repositories, SSH keys in memory, API tokens in environment variables. A malicious extension doesn’t steal a package — it steals the developer’s entire working context.

19 Extensions Running Deep Reconnaissance

Manifold Security categorized the extensions into two tiers. The 58 “light” extensions collected basic information: OS version, CPU type, VS Code version. Standard fingerprinting, likely aimed at identifying high-value targets.

The 19 “heavy” extensions went far further:

• Git metadata: repository names, active branches, remote URLs — enough to identify the organizations and projects the victim works on.
• CI environment variables: access tokens, private registry addresses, deployment keys. If the victim was developing on a machine connected to a CI/CD pipeline, these variables provide direct access to infrastructure.
• Local project paths: a complete map of the working directory tree, revealing the nature of projects (frontend, backend, infrastructure) and the technologies in use.

All of it was exfiltrated to a single attacker-controlled domain, uncovered by Manifold Security through post-installation network traffic analysis.

Open VSX: The Blind Spot in the VS Code Ecosystem

Open VSX is the extension registry used by the open-source forks of VS Code: VSCodium, Eclipse Theia, Gitpod, Code OSS. Unlike Microsoft’s Visual Studio Marketplace, which enforces Publisher Verification and runs automated scans on published extensions, Open VSX has historically operated with lighter moderation — a deliberate trade-off to maximize platform openness.

The attack exposes the tension between openness and security in plugin ecosystems. VS Code itself hosts over 50,000 extensions on Microsoft’s marketplace; Open VSX mirrors thousands more, often auto-synced from other sources. The attack surface is enormous, and automated detection — static analysis of extension code, sandboxing of post-install scripts — remains nascent.

Microsoft introduced the Extension Runtime Sandbox in 2025, isolating extensions in a separate process with restricted permissions. But this sandbox is only active on the official marketplace and doesn’t cover all attack scenarios. Open VSX has no equivalent.

What DevOps Teams Must Do Right Now

The 77-extension Open VSX attack is not an isolated incident. It fits a trend documented throughout 2026: 77% of developers use third-party IDE extensions, and the attack surface of these extensions now exceeds that of traditional software dependencies.

Here are the concrete steps for your teams:

• Audit your IDE extensions. If your developers use VSCodium or any Open VSX-based editor, run ls ~/.vscode-oss/extensions/ and cross-reference each extension against Manifold Security’s report.
• Block automatic post-install script execution. VS Code allows disabling install scripts via the extensions.autoUpdate setting. Manual audit of new installations is the next line of defense.
• Migrate production environments to Microsoft’s verified marketplace. Publisher Verification and the extension sandbox significantly reduce risk — even if they don’t eliminate it.
• Isolate development environments. A developer working on critical infrastructure code should not share the same machine and extensions as their side project IDE. Environment segmentation limits the blast radius of a compromised extension.
• Monitor outbound network connections from developer machines. The 77 extensions all exfiltrated to a single domain — a firewall rule on dev workstations would have caught the anomaly.

Verdict

The 77 Open VSX extensions attack shifts a paradigm. Software supply chains no longer stop at npm, PyPI, or Maven dependencies. They now extend all the way up to the tool that writes the code — the IDE and its extensions. A malicious “Prettier” plugin has as much power as a malicious npm package: it can steal your secrets, map your projects, and compromise your CI/CD pipelines.

If your team uses Open VSX-based editors, auditing extensions is no longer a best practice — it’s an immediate security obligation. The Manifold Security campaign lasted one week. The next one could run for a month without detection.

References

• BleepingComputer, « 77 Open VSX extensions found harvesting developer info », August 4, 2026, by Lawrence Abrams.
• Manifold Security, report on the Open VSX extension campaign, published August 4, 2026.
• Eclipse Foundation, « Open VSX Registry », accessed August 5, 2026.
• Microsoft, « VS Code Extension Runtime Sandbox », documentation, accessed August 5, 2026.