How GlassWorm wormed its way back into developers’ code — and what it says about open source security

Pervasive, evasive malware thought to have been eliminated has wormed its way back into development environments.

Just a little over two weeks after GlassWorm was declared “fully contained and closed” by the open source OpenVSX project, the self-propagating worm is once again targeting Visual Studio Code extensions, add-ons that enhance open source VS Code, providing new features, debuggers, and other tools to improve developer workflows. Researchers from Koi have discovered a new wave of infections and three more compromised extensions.

First discovered in October, GlassWorm employs undisplayable Unicode characters to make malicious code invisible to code editors in VS Code environments. The worm has also now wriggled its way into GitHub repositories, hiding payloads in AI-generated commits that appear to be legitimate code changes.

Released by a Russia-based attack group, the malware is infecting victims around the world. This included dozens of individual developers and enterprises in the US, Europe, Asia, South America, and “a major government entity” in the Middle East.

“Same attacker infrastructure, still fully operational,” the Koi researchers note. They add, “this isn’t just about compromised extensions anymore. This is about real victims, critical infrastructure at risk, and a worm that’s doing exactly what we warned it would do: Spreading through the developer ecosystem.”

Also compromising GitHub repos

The Koi researchers identified three new OpenVSX code extensions containing GlassWorm that were downloaded at least 10,000 times in total:

• adhamu.history-in-sublime-merge (downloaded 4,000 times)
• ai-driven-dev.ai-driven-dev (downloaded 3,300 times)
• yasuyuky.transient-emacs (downloaded 2,400 times)

All three GlassWorm extensions are “still literally invisible” in code editors, the researchers note. They are encoded in unprintable Unicode characters that look like blank space to the human eye, but execute as JavaScript.

The attackers have posted new transactions to the Solana blockchain that outline updated remote command-and-control (C2) endpoints for distributing malicious payloads. But while these transactions are fresh, the servers remain unchanged, the researchers note.

“This demonstrates the resilience of blockchain-based C2 infrastructure — even if payload servers are taken down, the attacker can post a new transaction for a fraction of a cent, and all infected machines automatically fetch the new location,” they write.

Developers are also reporting that their GitHub repositories have been compromised with commits that appear as “project-specific” AI-generated code changes as part of normal development activity. These commits feature the same invisible Unicode malware as those in VS Code. Further, attackers are stealing GitHub credentials and using worm techniques to push commits to additional repositories.

“It is deeply concerning but not surprising to see GlassWorm re‑emerge so quickly,” noted Ensar Seker, CISO at threat intel company SOCRadar.

What makes this especially dangerous is the way attackers resurfaced the supply chain worm after it was removed, he noted. “The removal of a few extensions isn’t enough when the attacker controls propagation mechanisms and leverages points across multiple marketplaces.”

Highlights a ‘fundamental weakness’

Interestingly, attackers seemed to have gotten sloppy with their own infrastructure, leaving an exposed endpoint that Koi researchers exploited to surface data and a partial list of victims. They also discovered from the threat actor’s keylogger data that they use the open source C2 framework browser extension RedExt, and were able to access attackers’ user IDs for multiple messaging platforms and cryptocurrency exchanges.

The victim list has since been turned over to law enforcement, victims are being notified, and an active investigation is underway, the Koi researchers note.

David Shipley of Beauceron Security called these exploits both technological, and process and market-driven. OpenVSX doesn’t seem to have the resources as a community to manually review submitted code, he noted, instead relying on automated tools and publisher agreements.

This problem highlights a “fundamental weakness” in the open source market model: Free or low-cost approaches means resources aren’t available and incentives aren’t aligned to apply the required level of security for today’s threat environment, said Shipley.

“Put simply, when you’re not paid enough to do manual code reviews, you don’t,” he noted. “When you don’t have humans who can think checking for clever hacks, the clever hacks get in.”

Question the value of OpenVSX

Security teams should question the value proposition of OpenVSX, Shipley advised. If they’re willing to manually review and send alerts about code from the open source registry, they can mitigate risk. Otherwise, they should consider getting code from a curated source with more review controls.

“Supply chain and open source are now ‘it’ in the global game of cybersecurity tag, and they’re going to stay ‘it’ for a long time,” said Shipley. This could potentially be the case until economics are rebalanced to allow for more security, or the model “collapses under the weight of insecurity.”

“There’s no automated AI magic pixie dust that can stop 100% of these threats reliably,” he said. “Good enough automated scans were good enough until attackers realized this was a tremendously viable attack delivery method.”

SOCRadar’s Seker agreed that the core issue isn’t the malware, but the “systemic shift” in supply chain threats.

“The software supply chain is no longer just about dependencies,” he said, but  rather, its toolchains, marketplaces, and the entire development ecosystem. “You’ve got to treat developer infrastructure like production infrastructure.”

Developers and security teams should key into critical signals: malicious extensions containing invisible Unicode characters being uploaded; hidden C2 channels using blockchain memos and legitimate services like Google Calendar to evade takedowns; and infected developer machines being used as proxy nodes to launch further infections.

Companies should reduce attack surfaces by only allowing components from trusted publishers, disabling auto‑updates where possible, and maintaining an inventory of installed extensions, Seker advised, as well as monitoring for abnormal outbound connections from workstations, credential harvesting activity for developer‑level tokens (npm, GitHub, VS Code), and proxy or VNC server creation. Further, security teams should apply the “same rigor” they use for third-party libraries to their own developer toolchains.

“When malicious actors treat your IDE [integrated developer environment] as the launch pad, your supply chain exposure expands drastically,” said Seker.

Ultimately, he warned: “These are not typical supply chain attacks where you patch a single library and move on. They’re architected to persist.”

This article originally appeared on InfoWorld.