Open VSX’s New Scanner Vulnerability Allows Malicious Extension

A significant security vulnerability has emerged within Open VSX, the extension marketplace that serves popular code editors like Cursor and Windsurf, alongside the broader VS Code fork ecosystem.

The vulnerability was found inside the platform’s newly introduced pre-publish scanning pipeline, a security layer built to check every extension before it becomes available to users.

The flaw, now referred to as “Open Sesame,” allowed a malicious extension to completely bypass security scanning and go live on the marketplace, appearing to users as if it had fully passed all safety checks.

The scanning pipeline was designed with good intentions. It was built to catch malware, scan for hardcoded secrets, check for suspicious binaries, and prevent name-squatting, where bad actors copy popular extension names to trick users into downloading harmful software.

The pipeline holds each uploaded extension in an inactive state until every registered scanner approves it. Only after passing all checks does the extension become downloadable.

This system, in theory, was a strong step forward for the security of the entire ecosystem.

Koi analysts and researchers identified that the root of the problem was a single boolean return value inside the scanning code.

This value was used to mean two very different things: either no scanners were set up at all, or all scanners failed to run during the process.

Since the system could not tell these two situations apart, it treated a total scanner failure the same way it treated a clean, unconfigured state.

The result was that the platform would mark the extension as “PASSED” and activate it for public download, even though no security scan had actually taken place.

The attack required no special access or insider knowledge. Any person with a free publisher account could exploit this flaw simply by flooding the publish endpoint with multiple upload requests at the same time.

This kind of heavy traffic would exhaust the database connection pool, causing scanner jobs to fail during the enqueuing process. With no successful scans submitted, the system still waved the extension through.

The vulnerability was responsibly reported to the Open VSX team on February 8, 2026. The team responded quickly and shipped a working fix on February 11, 2026, just three days after receiving the report.

How the Fail-Open Bug Worked in Practice

The technical issue lived inside two key files: ExtensionScanService.java and PublishExtensionVersionHandler.java. When the scan submission method ran and all scanner jobs failed to enqueue due to database overload, it returned a value of “false.”

The caller in the handler file interpreted this “false” as meaning no scanners were configured at all, which was considered a safe, normal state.

Instead of blocking the extension, the system called scanService.markScanPassed() and then activated the extension immediately for download.

What made this worse was that the same flawed logic existed inside ExtensionScanJobRecoveryService.java, which was specifically built as a backup system to retry failed scans. The safety net carried the same flaw as the system it was meant to protect.

An attacker could exploit this by preparing a batch of malicious .vsix extension files and submitting them all at once through the publish endpoint. With no rate limiting in place, repeated attempts cost nothing.

Each round of heavy publishing would strain the database connection pool until scanner job enqueuing started failing. Once that happened, the fail-open condition triggered, the extension went live, and nothing in the user interface showed that any check had been skipped.

Users who installed new or updated extensions from the Open VSX marketplace during the vulnerable window, which existed before the February 11, 2026 patch, should review those extensions carefully.

Developers building similar scanning pipelines should ensure that failure states are always handled separately from “nothing to do” states. A single return value should never be used to describe both a deliberate configuration choice and a system error.

When a scanner fails to run, the correct response is to block the extension, not approve it. Rate limiting on publish endpoints is also strongly advised to prevent connection pool exhaustion 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.