Open VSX Vulnerability lets malicious extension go live

A recently disclosed vulnerability in the Open VSX extension marketplace exposed a critical vulnerability in its newly introduced pre-publish scanning pipeline, allowing malicious extensions to bypass security checks and be published as “PASSED.”

The issue, informally dubbed “Open Sesame,” was responsibly reported on February 8 and fixed within three days, highlighting both the severity of the bug and the responsiveness of the Open VSX team.

The system was designed to scan extensions for malware, embedded secrets, suspicious binaries, and name-squatting attempts before making them publicly available.

The pipeline followed a structured flow. After upload, extensions remained inactive while undergoing two scanning phases: quick synchronous checks followed by asynchronous background scans.

According to the report, Open VSX, widely used by platforms like Cursor and Windsurf as an alternative extension registry for VS Code forks, has introduced a pre-publish scanning pipeline to improve ecosystem security.

Only after all scanners passed would the extension be activated for download. If any scanner flagged an issue, the extension would be quarantined for review.

This design aimed to ensure that no extension reached users without passing all security checks. However, a subtle logic vulnerability undermined this guarantee.

The “Fail-Open” Bug Explained

At the core of the vulnerability was a boolean return value used in the scanning logic. This value represented two very different conditions:

• No scanners configured (a valid scenario).
• All scanner jobs failed to execute (an error condition).

Because both scenarios returned the same value, the system could not distinguish between them. When scanner jobs failed especially under heavy load the system interpreted this as “nothing to scan” and automatically approved the extension.

The bug lives in how ExtensionScanService.java reports results, and how its caller interprets them. And here’s the caller in PublishExtensionVersionHandler.java:

As a result, extensions were marked as “PASSED,” activated, and made publicly downloadable without undergoing any actual security checks.

The issue was further compounded by similar logic in the recovery service, which was intended to retry failed scans. This meant the fallback mechanism also failed to detect and correct the issue.

Exploiting this vulnerability required no special privileges. Any user with a free publisher account could attempt it.

An attacker could upload multiple malicious extensions packaged as standard .vsix files and flood the publish API.

Each upload triggered scan job creation and queuing, which relied on shared database connections. Under heavy load, the system’s job scheduler would fail to enqueue scanning tasks due to exhausted resources.

These failures were silently caught and ignored, resulting in zero scanner jobs being registered. The system then returned the ambiguous “false” value, which the caller interpreted as a successful scan condition.

The outcome: malicious extensions were published and labeled as verified.

Testing confirmed that this fail-open condition could be reliably triggered under controlled load conditions. In production, while timing would be tighter, attackers could repeatedly attempt the process without cost or rate limits.

Impact and Remediation

The primary risk was that malicious extensions could appear legitimate to users, as there was no indication in the UI that scanning had been skipped. This created a significant supply chain risk within the developer ecosystem.

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

Open VSX addressed the issue on February 11 by removing the ambiguous boolean logic and ensuring that failure states are explicitly handled. The fix ensures that scanner failures no longer result in automatic approval.

This incident highlights a common but dangerous design vulnerability in security systems: fail-open behavior caused by ambiguous error handling.

When “no action needed” and “action failed” share the same outcome, security controls can collapse under stress.

Developers building similar pipelines should ensure that failure states are clearly differentiated and handled conservatively. In security-sensitive workflows, failure should default to denial, not approval.

Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.

The post Open VSX Vulnerability lets malicious extension go live appeared first on Cyber Security News.