“Open Sesame”: The Single Boolean That Let Malicious VS Code Extensions Bypass All Security Checks

Koi Security published a disclosure on March 27, 2026 describing a fail-open logic flaw in the Open VSX Registry, the extension marketplace used by Cursor, Windsurf, and other VS Code-compatible editors. Koi codenamed the bug Open Sesame. The registry’s new pre-publish scanning pipeline returned a single boolean value that meant two different things: no scanners are configured, and all scanner jobs failed to run. The calling code could not tell the difference, so when scanning failed, Open VSX treated the upload as having nothing to scan and published it. Koi Security researcher Oran Simhony reported the flaw to the Open VSX team on February 8, 2026. The maintainers acknowledged it and shipped a fix on February 11, in version 0.32.0.

How the Boolean Bypass Actually Worked

Expected pipeline behavior: Open VSX introduced mandatory pre-publish scanning in early 2026 to catch malicious extensions before they reach users. An uploaded extension is held in an inactive state while a set of registered scanners runs against it: malware detection, secret scanning, binary analysis. Extensions that fail are quarantined for admin review. Only after every scanner approves does the extension become downloadable.

The vulnerability: The scan-reporting logic in the registry’s Java service, ExtensionScanService.java, returned one boolean to its caller in PublishExtensionVersionHandler.java. That boolean represented both a legitimate configuration state (no scanners configured, nothing to do) and an error state (scanner jobs exist but could not be enqueued). When the error state occurred, the caller read it as the legitimate state, marked the extension as passed, and activated it for download. The pipeline’s design was sound. The failure handling was not: an error path collapsed into a nothing-to-do path, and the gate opened.

The exploitation path: The publish API had no rate limiting. An attacker with a free publisher account could flood it, exhausting the shared database connection pool the registry uses to schedule scan jobs. When job scheduling failed under that load, the fail-open condition triggered and the attacker’s extensions published without any scan running. Koi confirmed in testing that the condition triggers reliably under load. No special privileges, no stolen credentials, no infrastructure compromise. Upload, flood, wait.

Why Cursor and Windsurf Are Specifically Exposed

Microsoft’s VS Code Marketplace has its own separate backend and its own verification pipeline. Cursor and Windsurf, as VS Code-compatible editors built on the open-source base, cannot access the Microsoft Marketplace without licensing agreements. They use Open VSX as their primary extension source. That dependency made them the downstream victims of a registry-level vulnerability they did not introduce and could not patch unilaterally.

The Boolean Logic That Failed

The defect class is worth naming precisely. The pipeline’s return logic was structured as: if any scanner returns a positive detection, reject the extension. If all scanners return clean results, approve the extension. The defect was in how the pipeline handled a third state, scanner failure. When scanner jobs could not run, the pipeline returned the same boolean value as “nothing to scan.” The code did not distinguish between “no threats found,” “no scanners ran,” and “scanning broke.”

This is fail-open error handling hiding behind a code path designed for a legitimate nothing-to-do case, which is how Koi itself characterized it. The boolean value served two incompatible purposes: indicating whether there was scanning work to do AND indicating security clearance. A more defensive implementation would use distinct states (pass, fail, error) or would default to rejection when scanners fail. The implementation chose the permissive default, which is the wrong choice for a security-critical decision point.

Why This Matters Beyond Open VSX

Open VSX is the extension registry used by every VS Code fork that does not use Microsoft’s proprietary marketplace. Cursor, Windsurf, VSCodium, Gitpod, Eclipse Theia, and dozens of other editors and cloud IDEs pull extensions from Open VSX. The Eclipse Foundation reported in March 2026 that the registry had passed 300 million monthly downloads across more than 10,000 extensions. A malicious extension that passes through a broken security gate at that registry is immediately available to every developer using these tools.

The vulnerability was exploitable by anyone with a free publisher account on Open VSX. The attacker did not need to compromise the registry’s infrastructure, steal credentials, or find a complex exploitation chain. They needed to flood the publish endpoint until the scan scheduler failed, which caused the pipeline to approve their upload. The attack complexity was trivially low. The potential impact was high.

Koi Security reported the vulnerability responsibly and it was patched before known exploitation occurred. But the pattern it represents (security decisions defaulting to permissive when error states occur) is pervasive in software systems. The same logic error exists in firewall configurations that default to “allow” when the rule engine crashes, in authentication systems that default to “authenticated” when the identity provider is unreachable, and in content moderation systems that default to “approved” when the classifier times out. Every security gate that does not explicitly handle error states as rejections is vulnerable to the same class of bypass.

No malicious extensions are known to have been distributed through the bypass before the patch was applied. However, the vulnerability existed in a production registry during a window when any independent discoverer could have exploited it silently. Absence of known exploitation is not the same as confirmed non-exploitation, and users who installed new or updated extensions from Open VSX before the February 11 patch have no scanner guarantee for that window.

The Open VSX team fixed the fail-open logic within three days of the report by handling failure states explicitly, so scanner failure no longer results in automatic approval. The fix is the right fix. The systemic issue remains: non-Microsoft VS Code editors are structurally dependent on a lower-resourced registry with a smaller security team. That dependency will produce more vulnerabilities.

The fix for Open VSX was straightforward: treat scanner failure as a rejection, not a pass. The harder fix is auditing every security-critical decision point in every system for the same pattern. Most organizations have not done this audit because the failure mode is invisible until it is exploited. The absence of a security event is, by definition, not an event that security monitoring detects.

Sources: Koi Security, “Open Sesame” disclosure by Oran Simhony, March 27, 2026; The Hacker News coverage, March 27, 2026; Open VSX version 0.32.0 release; Eclipse Foundation Open VSX registry statistics, March 2026. Updated 2026-08-18: corrected the mechanism description, which previously attributed Open Sesame to a JavaScript type-coercion bug in a signature-validation API and to publication into a verified namespace. Koi Security’s primary disclosure describes a different flaw: a fail-open boolean in the Java scanning service that conflated “no scanners configured” with “scan jobs failed to run,” exploitable by flooding the unthrottled publish API until the scan-scheduling database pool was exhausted. Also corrected the timeline (reported February 8, fixed February 11 in version 0.32.0, disclosed publicly March 27) and the attribution: Open Sesame is Koi’s codename for the bug, not a researcher’s handle.