Open VSX Flaw Lets Malicious Extensions Bypass Scanner

Key Takeaways

• A critical “fail-open” vulnerability, dubbed “Open Sesame,” was discovered in the Open VSX extension marketplace.
• The flaw allowed malicious extensions to bypass the newly implemented pre-publish security scanner and appear as fully approved.
• The vulnerability affected popular code editors like Cursor and Windsurf, as well as the broader VS Code fork ecosystem.
• The issue stemmed from ambiguous boolean logic in the scanning pipeline that conflated scanner failure with a lack of configured scanners.
• A fix was rapidly deployed by the Open VSX team on February 11, 2026, just three days after responsible disclosure.

A significant security flaw has been identified within Open VSX, the prominent extension marketplace serving a range of code editors, including Cursor and Windsurf, alongside the wider VS Code fork ecosystem. This vulnerability, which allowed malicious extensions to circumvent security checks, highlights a critical oversight in the platform’s newly introduced pre-publish scanning pipeline.

The “Open Sesame” vulnerability enabled rogue extensions to go live on the marketplace, appearing to users as if they had successfully passed all mandated safety assessments, despite no actual scan occurring.

The Intent Behind the Scanner

The pre-publish scanning pipeline was implemented with the clear objective of bolstering marketplace security. Its design aimed to detect malware, identify hardcoded secrets, flag suspicious binaries, and combat name-squatting—a tactic where threat actors mimic popular extension names to trick users into downloading harmful software.

The system was designed to hold each uploaded extension in an inactive state until every registered scanner provided approval. Only upon successful completion of all checks would an extension become available for public download. This architecture was theoretically a robust enhancement to the security posture of the entire ecosystem.

The Root Cause: Ambiguous Logic

Analysts and researchers at Koi pinpointed the core of the problem to a single boolean return value within the scanning code. This value was ambiguously used to signify two distinct states: either no scanners were configured at all, or all configured scanners failed to execute during the process.

Because the system could not differentiate between these two scenarios, it treated a complete failure of the scanning mechanism identically to a state where no scanners were ever set up. Consequently, the platform would incorrectly mark the extension as “PASSED” and activate it for public download, even though no security review had been performed.

Exploiting the Fail-Open Flaw

Exploiting this vulnerability required no special access or privileged information. Any individual with a free publisher account could trigger the flaw by simultaneously flooding the publish endpoint with numerous upload requests. This deliberate surge in traffic would exhaust the database connection pool, causing scanner jobs to fail during the enqueuing process. With no successful scan submissions, the system would still erroneously greenlight the extension.

The vulnerability was responsibly disclosed to the Open VSX team on February 8, 2026. The team responded swiftly, deploying a working fix on February 11, 2026, a mere three days after the initial report.

How the Fail-Open Bug Worked in Practice

The technical issue resided within two critical files: ExtensionScanService.java and PublishExtensionVersionHandler.java. When the scan submission method executed and all scanner jobs failed to enqueue due to database overload, it returned a “false” value. The calling handler file misinterpreted this “false” as indicating that no scanners were configured, which was considered a safe, default state. Instead of blocking the extension, the system invoked scanService.markScanPassed(), immediately activating the extension for download.

Compounding the problem, the same flawed logic was present in ExtensionScanJobRecoveryService.java, a system specifically designed to retry failed scans. This safety net, intended to protect against scanning failures, unfortunately replicated the very flaw it was meant to mitigate.

An attacker could leverage this by preparing a batch of malicious .vsix extension files and submitting them concurrently through the publish endpoint. The absence of rate limiting allowed for repeated attempts without consequence. Each wave of heavy publishing would strain the database connection pool until scanner job enqueuing began to fail. Once this occurred, the fail-open condition would activate, the malicious extension would go live, and the user interface would display no indication that any security checks had been bypassed.

What You Should Do

• For Users: If you installed new or updated extensions from the Open VSX marketplace before February 11, 2026, it is strongly recommended to review those extensions carefully for any suspicious behavior or unexpected permissions.
• For Developers of Scanning Pipelines: Ensure that system failure states are always handled distinctly from “nothing to do” or unconfigured states. A single return value should never be used to represent both a deliberate configuration choice and a critical system error. When a scanner fails to execute, the default action should always be to block the extension, not approve it.
• Implement Rate Limiting: Apply robust rate limiting on all publish endpoints to prevent connection pool exhaustion and denial-of-service attacks through repeated flooding.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.