Barely two weeks after a coordinated takedown was meant to put GlassWorm out of business, the developer-targeting malware looks to be back — repackaged, renamed, and harder to spot than before.
Researchers with security vendor Socket have uncovered a covert operation that hides a malicious payload inside seemingly legitimate Visual Studio Code extensions, then uses the Solana blockchain to quietly fetch and run a second-stage attack.
Socket’s Threat Research team named the family GlassWASM, tying it with medium confidence to the developer behind GlassWorm. That’s the prolific supply-chain campaign Koi Security first flagged in October 2025. It went on to poison more than 400 components across npm, Open VSX, the VS Code Marketplace and GitHub. The campaign looked finished in late May, when a coordinated takedown led by CrowdStrike, Google and the Shadowserver Foundation severed all four of its command-and-control channels at once.
These extensions surfaced barely two weeks later — the operation, or something built from its parts, back on its feet with a new coat of paint.
The finding turns what could look like a two-extension cleanup problem into a larger warning about trust in developer tooling. Open VSX is used by VS Code-compatible editors and developer platforms, and GlassWorm-linked activity has repeatedly abused the registry this year through cloned extensions, sleeper packages and transitive dependency tricks.
The revamped technique here is not typosquatting. Rather than register a plausible misspelling and hope a developer fat-fingers it, the attacker cloned two real extensions wholesale and re-published them on Open VSX — the default registry for VS Code forks such as VSCodium, Cursor, Windsurf and Gitpod.
Each clone carries the original’s exact publisher ID, extension name, version string, description, README and even the upstream GitHub links. The genuine listings remain clean over on the Microsoft-run VS Code Marketplace, where publisher names are locked to verified owners; the poisoned copies exploit the trust gap between the two registries. A developer who searches Open VSX sees a name, version and repo that all match the listing they already trust.
The two carriers were both stale, low-profile projects unlikely to be missed by their authors: a black-background syntax theme (ExarGD.vsblack) and an Ethereum smart-contract debugger (noellee-doc.flint-debug) whose interface is themed around blockchain “transaction” debugging — handy cover for a payload aimed at crypto developers. A single three-day-old Open VSX account uploaded both. Socket says Open VSX pulled the listings quickly once it reported them.
When either extension activates — automatically, via an onStartupFinished hook — a WebAssembly module compiled with TinyGo loads and goes looking for instructions. That choice of packaging is what researchers zeroed in on.
CrowdStrike’s takedown report documented this crew continually swapping implementation languages to stay ahead of scanners, moving from JavaScript to Rust to Zig over the course of the campaign; compiling the logic to Go and shipping it as WebAssembly is the latest turn of that screw. And it works, because the module ships with no readable clues at all.
“The WASM module contains no plaintext network indicators, URLs, or commands; every string of consequence is encrypted in the binary with a ChaCha20 cipher and reconstructed in memory only at runtime,” the Socket researchers explained.
“This makes it difficult to detect by signatures simply using natural language or readable strings,” he said.
There’s no hardcoded server to seize, either. Instead of phoning a fixed domain, the module polls a single attacker-controlled Solana wallet through the public api.mainnet.solana.com API. Tucked into that wallet’s latest transaction — in the memo field, where Solana lets you attach a note — is the address of the server holding the next stage. The module pulls that address, builds a command to download and run whatever is waiting there, and executes it through Node’s child_process: curl … | bash on macOS and Linux, irm … | iex on Windows.
Using the blockchain as a dead-drop makes the channel takedown-resistant: there is nothing to sinkhole, and the operator can repoint every infected machine at fresh infrastructure just by posting a new transaction.
It’s a tactic CrowdStrike singled out when it dismantled GlassWorm, which hid its C2 behind four redundant resolution layers specifically to survive disruption: the Solana ledger, the BitTorrent DHT, Google Calendar event titles and conventional VPS servers.
CrowdStrike assessed the operators as well-resourced and likely based in Russia, citing runtime checks that spare machines in CIS countries and Russian-language comments throughout the code.
At the time of Socket’s analysis the resolved host wasn’t serving a payload, so the final-stage malware (an infostealer, a wallet drainer, or something else) couldn’t be confirmed. Socket’s team noted that the attackers worked as hard on the disguise as on the payload.
“Each malicious clone reproduces its target’s exact publisher ID, extension name, version string, description, README, and even the original author’s GitHub repository links, then adds the ChaCha20-obfuscated WASM payload and an onStartupFinished activation hook that runs it,” they said. “This is identity impersonation that exploits a cross-registry trust gap, not typosquatting. The publisher and extension names are identical to the originals.”
The registry’s operators have spent months on the back foot. After the first GlassWorm wave, the Eclipse Foundation, which runs Open VSX, revoked a batch of leaked publishing tokens and tightened its controls — shorter default token lifetimes, a scannable ovsxat_ token prefix developed with Microsoft’s response team, and automated checks for malicious code at publish time.
The Foundation’s head of security, Mikaël Barbero, also pushed back on the early impact estimates, saying the leaks were “caused by developer mistakes, not a compromise of the Open VSX infrastructure” and that headline download counts were padded by bot traffic the attackers used to manufacture credibility. GlassWASM suggests the cat-and-mouse is far from over.
Poisoning developer extensions and libraries has become a favored tactic for a simple reason: the payoff. Whereas a conventional network intrusion might net one victim organization, compromising a tool at the developer level opens the door to a supply-chain attack in which every downstream user inherits the exposure.
The campaign also shows why IDE extensions are becoming an attractive supply-chain target. Microsoft’s own VS Code security documentation warns that extensions run with the same permissions as VS Code itself and can read and write local files, make network requests and run external processes.
That puts a malicious extension close to source code, local .env files, SSH keys, cloud CLIs, package-publishing tokens, AI coding assistant credentials and other secrets that may live on a developer workstation.
The broader trend is not slowing. Sonatype said it identified more than 454,600 new malicious open source packages in 2025, bringing its cumulative count of known and blocked malware packages to more than 1.233 million.
Developer secrets are also spreading. GitGuardian said 28.65 million new hardcoded secrets were added to public GitHub commits in 2025, up 34% year over year.
Compiling the malicious logic to WebAssembly raises the stakes further. That’s because most package-scanning pipelines and human reviewers are tuned for JavaScript and TypeScript, and treat an opaque .wasm blob as something they don’t need to open.
Shaun Nichols is an IT news journalist. He has spent nearly 20 years covering the industry with a specialty in cybersecurity.
