Open VSX has removed three extension identifiers from its malicious-extension list after the legitimate projects they impersonated began reclaiming their names.
The move restores publishing access for the affected maintainers but highlights a supply-chain tracking gap: a single extension ID can represent both a removed malicious artifact and a later legitimate release.
Between August 16 and August 20, Open VSX unblocked AlDuncanson.react-hooks-snippets, magne-sjaastad.opm-flow-editor-support, and rumbledb.jsoniq-vscode.
The identifiers were among 77 names abused in an evil-twin campaign that copied legitimate VS Code Marketplace extensions into Open VSX under unauthorized publisher accounts.
The original campaign, documented by Manifold Security, ran between July 26 and August 1 and targeted extension names that already existed in Microsoft’s VS Code Marketplace but had not been claimed by their actual maintainers on Open VSX.
The attackers published counterfeit versions, generally at version 0.0.1, using unrelated accounts and cloned descriptions. All 77 samples communicated with the same recently registered mangorbit[.]com infrastructure.
Nineteen of the malicious extensions carried an expanded reconnaissance payload. Besides collecting host and editor metadata.
The code accessed Git configuration and repository context, including remote repository hosts, organization names, commit-email domains, branches, commit hashes, workspace paths, installed extensions, and CI/CD identifiers.
Socket’s reporting shows that the OPM Flow Editor Support and RumbleDB JSONiq/XQuery projects have now published legitimate packages, while React Hooks Snippets had reclaimed its namespace but had not yet published an official Open VSX release at the time of reporting.
On build runners or cloud development environments, collected fields could disclose private repository paths such as GITHUB_REPOSITORY or CI_PROJECT_PATH.
Evil-Twin Malware Campaign
Socket Researchers said that, Open VSX removed the full set of 77 malicious extensions by August 3 and added their IDs to a public control list.
However, the subsequent recovery process exposed a limitation in ID-only blocklisting. Open VSX’s public list records a malicious extension as a simple identifier without its package version, VSIX hash, publisher account, repository URL, or publication date.
Once a legitimate owner reclaims the same ID, retaining the block would prevent the official extension from being published; removing it, however, removes the identifier from the current malicious list even though a malicious package once used it.
The effect is already visible in the three restored names. The malicious packages reportedly used low-version releases such as 0.0.1, while legitimate releases now include [email protected], published August 21, and [email protected], published August 23.
Security tools or internal asset inventories that record only an extension ID cannot reliably distinguish the historical malware from the approved package now resolving under the identical name.
The broader namesquatting issue is significant. Socket engineer John Tuckner tracked 491 Open VSX IDs over the preceding year that corresponded to VS Code Marketplace projects, including 338 in 2026.
Of those, 415 impersonated extensions ranked among the 10,000 most popular in Microsoft’s marketplace, illustrating the scale of namespace gaps across separate extension ecosystems.
Open VSX has introduced safeguards that could improve forensic visibility going forward.
Its 1.1.x release added immutable extension versions, preventing publishers from modifying an already published version, and a preview Registry Changes Feed that logs publication, deactivation, and removal events.
The append-only feed can help security teams preserve lifecycle history, although public guidance for handling identifiers reclaimed after malicious use has not yet been established.
For defenders, the incident reinforces that an extension name is not a sufficient indicator of trust.
Organizations should retain the extension ID alongside the exact version, VSIX hash, publisher identity, source repository, installation source, and first-seen date.
Historical detections should remain tied to the malicious artifact rather than being broadly applied to an identifier that may later be recovered by its legitimate owner.
Extension maintainers should also claim their Open VSX namespaces before an attacker can do so, even where the registry is not yet a primary distribution channel.
For enterprise teams, copied .vscode/extensions.json, devcontainer configurations, and automated developer-environment provisioning should validate publisher ownership and package provenance rather than resolving extensions by a familiar name alone.
★ Which Security Tools Should You Cut? Score Them on One Page – Download the Inherited Security Stack Guide
