Open VSX Unblocks Extension IDs Used in Malware Campaign

Open VSX Unblocks Extension IDs Used in Malware Campaign Open VSX has removed three extension IDs from its malicious-extension list as the legitimate publishers they impersonated move to claim the names for themselves. - Sarah Gooding Over a five-day period from August 16 through August 20, the registry unblocked AlDuncanson.react-hooks-snippets , magne-sjaastad.opm-flow-editor-support , and rumbledb.jsoniq-vscode . All three IDs had been used by impostors in the 77-extension evil-twin campaign documented by Manifold Security earlier this month. Legitimate versions of the OPM and RumbleDB extensions are now live. React Hooks Snippets has been unblocked, but its legitimate Open VSX listing had not appeared as of publication. The cleanup addresses a problem created by namesquatting across two separate marketplaces. It also exposes the limits of tracking a malicious extension by ID alone. An identifier can first belong to an impostor and later return under the control of the project it copied, while the malicious artifact remains part of the incident history. Three Publishers Moved to Reclaim Their IDs React Hooks Snippets maintainer Al Duncan requested an unblock on August 16 after his first attempt to publish to Open VSX failed with the message: AlDuncanson.react-hooks-snippets is a known malicious extension . Duncan noted that the ID had been added to the list during the evil-twin campaign. An Open VSX maintainer apologized for the disruption, confirmed that it was tied to the campaign, and removed the ID from the malicious list later that day. The publisher also claimed the AlDuncanson namespace, though no legitimate version had appeared in Open VSX by August 24. The OPM case began with another August 16 request from the maintainer of OPM Flow Editor Support. The extension had been available in Microsoft's VS Code Marketplace, but an attempt to publish it to Open VSX failed with the message: magne-sjaastad.opm-flow-editor-support is a known malicious extension . An Open VSX maintainer confirmed ownership and said the ID had been caught up in a malware campaign. On August 18, Open VSX removed the ID from its malicious-extension list. The legitimate magne-sjaastad.opm-flow-editor-support@0.9.0 was published on August 21. The third request came from the maintainer of RumbleDB's JSONiq and XQuery extension. The project had already claimed the RumbleDB namespace after showing that it controlled the corresponding VS Code Marketplace publisher and source repository. The maintainer said a malicious copy had previously taken the ID on Open VSX. After the legitimate extension was uploaded, it disappeared from the registry a few hours later because rumbledb.jsoniq-vscode was still on the malicious list. Open VSX removed the ID on August 20, and the legitimate RumbleDB.jsoniq-vscode@1.6.0 went live on August 23. Open VSX had removed all 77 packages by August 3 and added the IDs to its malicious-extension list. The legitimate publishers were not compromised and were not involved in the campaign. Attackers had taken extension names that were already established in Microsoft's marketplace but had not yet been claimed by their real owners on Open VSX. The malicious versions are no longer available from Open VSX. All three IDs have been removed from the current malicious-extension list, and two now resolve to legitimate packages. Reused Extension IDs Complicate Malware Tracking Open VSX's public extension-control file represents malicious extensions as an array of ID strings. An entry contains no version, file hash, publisher account, repository, or date. That model works while every version under an ID is considered malicious. It becomes ambiguous once the legitimate owner reclaims the name. Leaving the ID on the list would block the real extension. Removing it allows the legitimate package to be distributed, but the current list no longer shows that malicious code previously used the same identifier. The Git history preserves the earlier entries and their removal. Security products and internal inventories that store only the current ID, however, cannot distinguish the deleted 0.0.1 malware from the legitimate 0.9.0 and 1.6.0 releases now using those names. Socket engineer John Tuckner has been tracking how frequently attackers and researchers claim extension IDs that belong to projects in the VS Code Marketplace. In a July 31 post, Tuckner said his records showed 491 such Open VSX IDs over the previous year, including 338 in 2026. Of those 491 IDs, 415 impersonated extensions ranked among the 10,000 most popular in Microsoft's marketplace. These trends show how much malicious history could eventually collide with legitimate publishing. An unclaimed name may be abused first and reclaimed by its real owner later. A Precedent for Reclaiming Blocked Extension IDs A review of the full Git history for Open VSX's malicious-extension list found an earlier case with the same basic publishing conflict. The registry added carbon-lang.carbon-vscode to the list on March 17. On April 1, the Carbon Language project had the ID removed from the banlist so it could publish its official extension. The verified package went live the next day. The public record does not explain why the Carbon ID was originally added or identify the earlier package as part of a named campaign, so Socket is not counting it among the three confirmed restorations from the August evil-twin operation. The same Git history also contains removals that were explicitly described as false positives or corrections, including Anthropic.claude-code , juanblanco.solidity , and donebd.vscode-keypromoter . Two more IDs, rbxdev.rbxdev-ls and TASKING-winIDEA.TASKING-winIDEA , were removed without a public explanation that establishes whether they were reclaimed, corrected, or cleared for another reason. A blocklist deletion by itself does not prove that a malicious namespace was restored to its legitimate owner. So far, Open VSX has not announced a general policy for reclaimed IDs. The three August decisions appear only in GitHub issues and commits. Its August 12 release announcement introduced immutable extension versions and a preview changes feed that records publications, deactivations, and removals, but the public documentation does not explain how consumers should treat an ID that moves from a malicious publisher to a verified legitimate owner. Teams Need to Track More Than the Extension Name Organizations using Open VSX should record the extension ID together with its exact version, file hash, publisher identity, and source repository. Historical deny rules should stay attached to the malicious artifact even when the ID returns to legitimate use. Teams should also verify the publisher before transferring extension recommendations, profiles, or .vscode/extensions.json configurations from VS Code to an editor that resolves packages through Open VSX. Matching names across the two marketplaces do not guarantee matching owners or code. Extension maintainers can reduce that opportunity by claiming their Open VSX namespace before someone else does, even if Open VSX is not yet their primary distribution channel. Socket scans Open VSX extensions for activation behavior, file system access, native code, network requests, obfuscation, and other risky capabilities. Evaluating the actual extension artifact preserves the distinction that an ID-only blocklist loses when a legitimate project reclaims a previously abused name.