Open VSX Bug Let Malicious VS Code Extensions Bypass Pre-Publish Security Checks
好的,我现在需要帮用户总结这篇文章的内容。用户的要求是用中文总结,控制在100字以内,不需要特定的开头,直接写描述即可。 首先,我通读了整篇文章。文章主要讲的是Open VSX平台的一个安全漏洞,这个漏洞被修补了。Koi Security的研究人员发现,Open VSX的预发布扫描管道有一个布尔返回值的问题,导致恶意的VS Code扩展能够绕过审查并发布。 接下来,我需要提取关键信息:漏洞名称是“Open Sesame”,问题出在扫描结果的报告机制上,误将扫描失败当作没有配置扫描器处理。攻击者可以利用这个漏洞上传恶意扩展,而无需特殊权限。最终在版本0.32.0中修复了这个问题。 现在我要把这些信息浓缩到100字以内。确保包含漏洞名称、问题原因、攻击方式和修复情况。 最后检查一下是否符合用户的要求:用中文、简洁明了、不使用特定开头。 </think> Koi Security发现Open VSX预发布扫描管道存在漏洞(代号Open Sesame),因布尔返回值混淆导致恶意VS Code扩展通过审查并发布。攻击者可利用此漏洞上传恶意扩展。该问题已修复于Open VSX 0.32.0版本。 2026-3-27 13:57:0 Author: thehackernews.com(查看原文) 阅读量:0 收藏

Software Security / DevSecOps

Cybersecurity researchers have disclosed details of a now-patched bug impacting Open VSX's pre-publish scanning pipeline to cause the tool to allow a malicious Microsoft Visual Studio Code (VS Code) extension to pass the vetting process and go live in the registry.

"The pipeline had a single boolean return value that meant both 'no scanners are configured' and 'all scanners failed to run,'" Koi Security researcher Oran Simhony said in a report shared with The Hacker News. "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."

Early last month, the Eclipse Foundation, which maintains Open VSX, announced plans to enforce pre-publish security checks before VS Code extensions are published to the repository in an attempt to tackle the growing problem of malicious extensions.

With Open VSX also serving as the extension marketplace for Cursor, Windsurf, and other VS Code forks, the move was seen as a proactive approach to prevent rogue extensions from getting published in the first place. As part of pre-publish scanning, extensions that fail the process are quarantined for admin review.

The vulnerability discovered by Koi, codenamed Open Sesame, has to do with how this Java-based service reports the scan results. Specifically, it's rooted in the fact that it misinterprets scanner job failures as no scanners are configured, causing an extension to be marked as passes, and then immediately activated and made available for download from Open VSX.

At the same time, it can also refer to a scenario where the scanners exist, and the scanner jobs have failed and cannot be enqueued because the database connection pool is exhausted. Even more troublingly, a recovery service designed to retry failed scans suffered from the same problem, thereby allowing extensions to skip the entire scanning process under certain conditions.

An attacker can take advantage of this weakness to flood the publish endpoint with several malicious .VSIX extensions, causing the concurrent load to exhaust the database connection pool. This, in turn, leads to a scenario where scan jobs fail to enqueue.

What's notable about the attack is that it does not require any special privileges. A malicious actor with a free publisher account could have reliably triggered this vulnerability to undermine the scanning process and get their extension published. The issue was addressed in Open VSX version 0.32.0 last month following responsible disclosure on February 8, 2026.

"Pre-publish scanning is an important layer, but it's one layer," Koi said. "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."

Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.


文章来源: https://thehackernews.com/2026/03/open-vsx-bug-let-malicious-vs-code.html
如有侵权请联系:admin#unsafe.sh