Open VSX, the extension marketplace used by VS Code forks such as Cursor and Windsurf, recently fixed a critical vulnerability in its newly introduced pre-publish scanning pipeline that could allow malicious extensions to bypass security checks and go live undetected.
The issue, dubbed “Open Sesame,” stemmed from a fail-open condition in the scanning workflow.
While the platform introduced the pipeline to strengthen extension security through malware detection, secret scanning, and binary analysis, a logic vulnerability allowed attackers to bypass all scanners under certain conditions.
The vulnerability was responsibly disclosed on February 8, 2026, and patched within three days on February 11. The issue and shipped a fix on February 11th. Fast, professional, and exactly how you’d hope a disclosure goes.
How the scanning pipeline works
The Open VSX scanning system was designed as a multi-stage verification process to ensure extensions are safe before becoming publicly available.
When a developer uploads an extension, it is initially stored in an inactive state. A set of fast, synchronous checks runs immediately, rejecting any obviously malicious content.
If these checks pass, the system schedules multiple asynchronous scanning jobs, each responsible for deeper analysis, such as malware detection or identifying exposed secrets.
Only after all scanners report success does the extension become publicly downloadable. If any scanner flags an issue, the extension is quarantined for manual review. A recovery service also exists to retry failed or stalled scans, ensuring reliability.
This layered approach was intended to guarantee that no extension reaches users without passing all configured security checks.
The root cause of the issue lies in how the system handled scanner execution results. A key method in the backend returned a Boolean value indicating the outcome of scanner submissions. However, this single value represented two entirely different scenarios:
- No scanners configured (a valid condition).
- All scanner jobs failed to execute (an error condition).
The system treated both outcomes identically. When scanner jobs failed such as during high load when database connections were exhausted the method returned “false.”
The calling service misinterpreted this as “no scanners configured” and automatically marked the extension as passed.
As a result, extensions could be published without undergoing any security checks, yet still appear as fully verified.
Mitigations
The attack required no special privileges. Any user with a standard publisher account could exploit the vulnerability.
An attacker could upload multiple malicious extensions while simultaneously flooding the publish API.
This surge in requests could overwhelm backend resources, particularly the shared database connection pool used for scheduling scan jobs. When job scheduling failed, the system skipped scanning entirely.
In testing, researchers confirmed that this fail-open condition could be triggered reliably under load. Since there was no rate limiting on the publish endpoint, attackers could repeatedly attempt exploitation at no cost.
Critically, extensions that bypassed scanning were indistinguishable from legitimate ones in the user interface, showing a “PASSED” status despite never being analyzed.
The Open VSX team quickly addressed the issue by removing the ambiguous boolean logic and ensuring failure states are handled explicitly. Scanner job failures no longer result in automatic approval.
Users who installed or updated extensions during the affected window are advised to review them as a precaution.
This incident highlights a broader secure design lesson: fail-open logic can undermine even well-designed security systems. When error states are indistinguishable from valid conditions, safeguards can silently collapse under pressure.
Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.
