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

A researcher known as Open Sesame disclosed in March 2026 that the Open VSX Registry (the extension marketplace used by Cursor, Windsurf, and other VS Code-compatible editors) contained a type confusion vulnerability in its signature validation API. The registry accepted the string “false” as a truthy value when checking whether an extension had passed author signature verification. This allowed an attacker to publish extensions to Open VSX that appeared signed without actually being signed, bypassing the trust model that Cursor and Windsurf use to validate extensions before installation.

How the Boolean Bypass Actually Worked

Expected API behavior: The Open VSX API accepts a JSON payload during extension publication that includes a field like "verified": true or "verified": false. The API should treat false (boolean) as: extension not verified, block publication to the verified namespace.

The vulnerability: The API performed a truthy check rather than a strict boolean equality check. In JavaScript/TypeScript, the string “false” is truthy (non-empty string). Sending "verified": "false" (string, not boolean) caused the server-side check to evaluate the string as truthy and mark the extension as verified. Classic type coercion bug in a dynamically typed environment.

What this allowed: An attacker who could publish to Open VSX (anyone with an account) could push extensions into the verified namespace without possessing the namespace owner’s private signing key. Cursor and Windsurf display verified extensions with a trust indicator. Users installing a malicious extension had no visual signal that the extension lacked a legitimate author signature.

Why Cursor and Windsurf Are Specifically Exposed

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

The Boolean Logic That Failed

Open VSX’s pre-publish pipeline runs security scanners against every extension upload before allowing it into the registry. 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 a scanner failed to execute (due to timeout, database load, or misconfiguration), the pipeline returned the same boolean value as “all scanners passed.” The code did not distinguish between “no threats found” and “no scanners ran.”

This is a classic confused deputy problem. The boolean value served two incompatible purposes: indicating scan completion status AND indicating security clearance. A more defensive implementation would use three 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. A malicious extension that passes through Open VSX’s broken security gate is immediately available to every developer using these tools. The blast radius of this single boolean defect spans millions of developer environments.

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 upload an extension at a time when the scanner database was under load, causing the scanner to fail, which caused the pipeline to approve the upload. The attack complexity was trivially low. The potential impact was catastrophically high.

Koi Security researcher Oran Simhony 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.

Open Sesame disclosed the vulnerability without weaponizing it. No malicious extensions were distributed through the bypass before the patch was applied. However, the vulnerability existed in a production API. Any attacker who independently discovered it during that window could have silently published malicious extensions to Cursor and Windsurf users’ verified namespaces. Absence of known exploitation is not the same as confirmed non-exploitation.

The Open VSX team patched the boolean coercion within 48 hours and re-validated extensions in the verified namespace. 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: Open VSX GitHub security advisory, March 2026; Cursor security bulletin; Windsurf disclosure; Eclipse Foundation incident report.