‍TL;DR: Open VSX's new pre-publish scanning pipeline had a fail-open bug. Flood the publish endpoint, the scanner skips, and your malicious extension goes live - marked as PASSED. Fixed within three days of our report.

  •  •  •

‍Open VSX, the extension marketplace behind Cursor, Windsurf, and the broader VS Code fork ecosystem, recently rolled out a pre-publish scanning pipeline. That's a big deal, and the right move. Malware detection, secret scanning, binary analysis, name-squatting prevention. Exactly the kind of infrastructure the ecosystem desperately needed.

Here's the thing. The pipeline had a single boolean return value that meant both "no scanners are configured" and "all scanners failed to run." The caller couldn't tell the difference. So when scanners failed under load, Open VSX treated it as "nothing to scan for" and waved the extension right through.

Any malicious actor with a free publisher account could exploit this. No special privileges. No insider access. Just flood the endpoint and wait.

We reported this to the Open VSX team on Sunday, February 8th. They acknowledged the issue and shipped a fix on February 11th. Fast, professional, and exactly how you'd hope a disclosure goes. Kudos to the team.

We're calling it Open Sesame. Let’s see how everything unfolds.

The Scanning Pipeline

In response to the growing threat of malicious extensions, the Open VSX team began implementing a pre-publish scanning pipeline (Issue #1331, PR #1529). The vision: an extensible verification system that inspects every extension before publication. Malware detection, name-squatting prevention, secret scanning. Extensions that fail get quarantined for admin review.

The pipeline works like this:

1. A publisher uploads an extension via the API.
2. The extension is saved but remains inactive and not downloadable until scanning completes.
3. The scan runs in two phases. First, fast synchronous checks run inline, if any check fails, the extension is rejected immediately. Second, all registered scanners are submitted as parallel background jobs.
4. A completion service monitors these jobs and, once all pass, activates the extension for download. If any scanner flags a threat, the extension is quarantined for admin review.
5. A separate recovery watchdog periodically checks for stuck or failed scans and re-enqueues them.

No extension reaches users without passing every configured scanner. That's the guarantee. Now let's look at how it breaks.

The Open Sesame Bug

The bug lives in how ExtensionScanService.java reports results, and how its caller interprets them.

Here's the scan submission method:

And here's the caller in PublishExtensionVersionHandler.java:

See the problem? That boolean conflates two completely different situations:

(A) No scanners are configured. A deliberate admin choice. Safe to activate.

(B) All scanner job enqueues failed. A transient error under load. NOT safe to activate.

When submitScannerJobs returns false, the caller assumes (A) every single time. Extension gets marked as passed, activated, made downloadable. But under load, that same false actually means (B). The scanners exist. They just couldn't be enqueued because the database connection pool is exhausted.

And it gets worse. The same pattern existed in ExtensionScanJobRecoveryService.java - the recovery path specifically designed to catch and retry failed scans. The safety net had the same hole as the system it was supposed to back up.

What Exploitation Looks Like

There are no special prerequisites, an attacker only needs a user! They prepare a batch of malicious extensions, each packaged as a standard .vsix file containing whatever payload they want, and flood the publish endpoint.

Here's why that works: each publish triggers the scanning pipeline, which needs to save ScanJob records and enqueue them to JobRunr. Both operations compete for database connections from the same shared pool. Under sufficient concurrent load, jobScheduler.enqueue() starts throwing exceptions. The catch block logs the error and moves on. Every scanner fails to enqueue. enqueuedCount stays at zero. The method returns false.

The gate opens. The extension goes live on open-vsx.org. Scan status: PASSED.

We confirmed this behavior in testing under controlled conditions, we were able to reliably trigger the fail-open path. The race window on any single attempt in production would be tight, but the attacker can retry indefinitely at zero cost with no rate limiting on the publish endpoint. It's a matter of when, not if.

The extensions that slip through are indistinguishable from any other extension on the marketplace. Nothing in the UI tells a developer that the extension skipped every security check. It looks exactly like it passed.

The Fix

As always, the OpenVSX team did a great job closing this vulnerability, responded immediately and fixed it in a matter of 3 days.

The clean fix addresses the core ambiguity. No more ambiguous booleans. Failure means failure.

What You Should Do

The immediate risk is resolved. Open VSX shipped the fix on February 11th. If you installed new or updated extensions during the vulnerable window, consider reviewing them.

Beyond this specific bug, it's worth thinking about what this pattern means more broadly. Pre-publish scanning is an important layer, but it's one layer. The pipeline's design is sound, but a single boolean that couldn't distinguish between "nothing to do" and "something went wrong" turned the entire infrastructure into a gate that opened under pressure. This is a common anti-pattern: fail-open error handling hiding behind a code path designed for a legitimate "nothing to do" case.

If you're building similar pipelines, make failure states explicit. Never let "no work needed" and "work failed" share a return value.

This is also the kind of gap Koi is built to catch. Our risk engine analyzes extension behavior in depth, network requests, file system access, code patterns, catching malicious intent regardless of whether a marketplace scanner ran. Book a demo to see how.

Disclosure Timeline

• 2026-02-08 (Sunday): Vulnerability reported directly to the Open VSX team
• 2026-02-11 (Tuesday): Open VSX team acknowledged the report
• 2026-02-11 (Tuesday): Fix shipped in commit 64720cc

CWEs

• CWE-636 (Not Failing Securely): The core issue - scanner failure resulted in the extension being approved rather than blocked.
• CWE-755 (Improper Handling of Exceptional Conditions): The enqueue() exception was caught and logged but didn't change the outcome.
• CWE-362 (Race Condition): The exploit depends on timing concurrent publishes to exhaust the connection pool during scanning.
• CWE-400 (Uncontrolled Resource Consumption): No rate limiting on the publish endpoint allowed unbounded connection pool exhaustion.

‍