Open VSX flaw exposed extension gate

A critical weakness in Open VSX’s new pre-publication scanning system allowed malicious extensions to pass security checks and become publicly available, raising fresh concerns over the safety of a software marketplace relied on by Cursor, Windsurf and other tools built on the VS Code extension ecosystem. The flaw, dubbed “Open Sesame” by Koi Security, has been patched, with Open VSX maintainers fixing it in version 0.32.0 after the issue was reported on 8 February.

The vulnerability lay in the logic of the marketplace’s newly introduced scanner pipeline. According to Koi’s disclosure, the system used a single boolean return value to represent two very different states: one in which no scanners were configured, and another in which scanners existed but failed to run. That distinction mattered because the pipeline treated both outcomes as effectively clean, allowing an extension to be marked as having passed checks and then activated for download. Under load, scanner jobs could fail to enqueue when the database connection pool was exhausted, creating a fail-open path that an attacker could exploit with nothing more than a standard publisher account.

Chronology is important here. The Eclipse Foundation began building the verification framework in September 2025, defining goals such as malware detection, namespace protection, secret scanning and quarantine for suspicious uploads. A follow-on implementation milestone published in November 2025 set out concrete checks including blocklists, credential scanning, YARA rules and ClamAV-style malware detection. Production workflow records show security scanning was enabled in February 2026, with version 0.32.0 deployed shortly afterwards. That means the defect emerged not in a legacy safeguard, but in a newly erected front-line control designed to harden the registry after a turbulent year for extension supply-chain security.

The size of the risk helps explain why the disclosure matters beyond a niche developer audience. Open VSX is no longer a marginal alternative marketplace. The Eclipse Foundation said on 3 March that the registry had surpassed 300 million monthly downloads, served peak daily traffic above 50 million requests, and hosted more than 10,000 extensions from over 6,500 publishers. It also described Open VSX as a vendor-neutral backbone for AI-enabled and cloud-based developer platforms, naming Cursor, Windsurf, Amazon’s Kiro, Google’s Antigravity, VSCodium and others among the tools drawing on the registry. A weakness in the publication gate of such an ecosystem has implications not only for individual coders but for software supply chains that now run through AI-native editing environments.

The episode also lands against a backdrop of sustained attacks on developer extension channels. Koi and other security outlets have documented multiple campaigns over the past year targeting Visual Studio Code and Open VSX users through malicious extensions, token leaks and namespace abuse. Open VSX was hit by GlassWorm in late 2025, and Koi’s March reporting described a broadened wave of malicious Open VSX extensions in 2026. Another strand of research this year uncovered AI-branded VS Code add-ons siphoning code and files from developers. Seen in that wider pattern, the scanner bypass was not merely a theoretical coding flaw. It touched one of the few defensive layers meant to stop poisoned extensions before they reached users.

There is, however, a more balanced reading than alarm alone. The bug was found and disclosed through responsible channels, and the fix appears to have been shipped quickly. Koi said the issue was corrected within days of its report. Open VSX’s public documentation still shows a scanning model that rejects extensions for secrets, blocklisted files and suspicious namespace similarity, while the Eclipse Foundation has continued to frame the framework as an evolving system rather than a finished shield. Its March statement also pointed to rate-limiting and traffic-management work, suggesting maintainers had already recognised that resilience under heavy automated load was part of the security problem, not separate from it.