Between March 3 and March 9, 2026, someone injected malicious code into 151 GitHub repositories. The code was hidden in Unicode characters that produce zero visual output: no glyphs, no whitespace indicators, nothing. In every code editor, terminal, and code review interface, it rendered as empty lines.
The commits that delivered the malware weren't suspicious either. Documentation tweaks. Version bumps. Small refactors. Each one stylistically consistent with the target project, because they were generated by a large language model trained to blend in.
The campaign is called GlassWorm. The name comes from Koi Security's original discovery in October 2025: "Like glass, it's completely transparent." Five months later, it's still working. The 151 repos are just the latest wave in a campaign that has also compromised 72 VS Code extensions, multiple npm packages, and at least 35,800 developer installations.
Open source security rests on a simple assumption: humans review code, and that review catches malicious changes. GlassWorm broke that assumption twice. The malicious code is invisible to human eyes. The context surrounding it is AI-generated to pass human judgment. Code review didn't fail because reviewers were careless. It failed because the attack was designed to exploit the fundamental limits of how humans process information.
Malware That Doesn't Exist on Screen
GlassWorm's core technique exploits Unicode Private Use Area characters in the ranges U+FE00 to U+FE0F and U+E0100 to U+E01EF. These are variation selectors, characters that the Unicode specification designates as producing no visual output. Every editor, every terminal emulator, every browser-based code review tool renders them as nothing.
The payload is encoded directly inside JavaScript string literals that appear empty. A small decoder function extracts the real bytes from these invisible characters and passes them to execution. To a developer reading the file, it looks like blank lines between normal code. To the JavaScript runtime, it's executable instructions.
This isn't obfuscation. Obfuscated code is visible but hard to read. GlassWorm's malicious code is not visible at all. As Koi Security put it: "The malware is invisible. Not obfuscated. Not hidden in a minified file. Actually invisible to the human eye."
I wrote about malicious VS Code extensions compromising the IDE security perimeter when attackers used the extension marketplace to reach 1.5 million developers. GlassWorm takes the same distribution channels and adds a layer that makes the payload undetectable through visual inspection. The attack surface didn't change. The visibility did.
The AI-Generated Cover Story
The invisible payload is only half the problem. The other half is how it gets delivered.
Aikido Security's analysis found that the malicious injections don't arrive in obviously suspicious commits. The surrounding changes are realistic: documentation tweaks, version bumps, small refactors, and bug fixes that are "stylistically consistent with each target project." Security researcher Ilyas Makari noted that manually crafting 151 bespoke code changes across different codebases simply isn't feasible. The attackers are using large language models to generate context-appropriate cover commits.
This is a fundamentally new problem. Traditional supply chain attacks rely on either compromising a maintainer's account or submitting malicious pull requests that hope to slip past review. Both are detectable with sufficient diligence. GlassWorm's approach defeats diligence itself. A reviewer examining the commit sees legitimate-looking changes to documentation or test files, with the actual payload hidden in characters that their editor won't display.
When I wrote about VoidLink's 88,000 lines of AI-generated malware, the key finding was that AI-generated code leaves forensic fingerprints: verbose logging, template artifacts, uniform versioning. VoidLink's developer got caught because AI produces recognizable patterns. GlassWorm's operators learned from that. They're using AI not to write the malware itself, but to write the camouflage around it. The malicious payload is handcrafted and invisible. The AI handles only the social engineering layer: making the delivery mechanism look normal.
A Worm That Feeds on Developer Trust
GlassWorm isn't a static payload. It's a self-propagating worm, the first of its kind targeting developer tool ecosystems.
The infection chain works like this: the invisible decoder fetches a second-stage payload by querying the Solana blockchain. The attacker posts transactions to a hardcoded wallet address containing base64-encoded URLs in the memo field. Each infected system reads the blockchain to find its next instructions. The cost per C2 update is approximately 0.000005 SOL, essentially free.
The final payload is a full remote access trojan called ZOMBI. It harvests NPM authentication tokens, GitHub credentials, OpenVSX access tokens, and Git credentials. It targets 49 cryptocurrency wallet extensions for direct fund draining. It deploys SOCKS proxy servers and hidden VNC clients on infected workstations, turning developer machines into nodes in a criminal proxy network.
Then it uses the stolen credentials to compromise more packages and extensions. Each infected developer becomes an infection vector. The worm grows exponentially through the very trust infrastructure that open source depends on.
The blockchain C2 creates a problem that the security community hasn't solved. Traditional malware command-and-control can be disrupted by seizing domains or pressuring hosting providers. Solana transactions are permanent and censorship-resistant by design. Even if defenders identify and block a payload URL, the attacker posts a new transaction with a different URL, and every infected system automatically fetches the new location. There is no takedown mechanism because the infrastructure was built to be untakeable.
The malware also runs locale checks and skips execution on Russian-language systems, a classic indicator of CIS-origin threat actors. It maintains backup C2 channels through Google Calendar events and direct IP connections encrypted with AES-256-CBC, ensuring resilience even if one channel is discovered.
Three Assumptions That No Longer Hold
GlassWorm matters because it simultaneously broke three assumptions that underpin how the software industry manages supply chain risk.
Assumption one: code review catches malicious changes. This was already under pressure. Code review fails to catch vulnerabilities in AI-generated code nearly half the time, and the scale of modern dependency trees was straining the model long before GlassWorm, as I discussed in the context of CI/CD trust models after CodeBreach. GlassWorm made it categorical. You cannot review what you cannot see. No amount of reviewer training, mandatory approvals, or review tooling fixes the fundamental problem that these characters produce no visual output. The security control assumes visibility. The attack removes it.
Assumption two: credential compromise is a discrete incident. Traditional credential theft is bad, but contained: one set of stolen credentials compromises one account. GlassWorm turns credential theft into a propagation mechanism. Every stolen NPM token or GitHub credential isn't just access to one developer's projects. It's a launch point for infecting every package and extension that developer maintains. The blast radius scales with the victim's publishing footprint.
Assumption three: malicious infrastructure can be disrupted. Domain seizures, hosting provider takedowns, and coordinated law enforcement action have been effective tools against malware C2 for decades. Blockchain-based C2 renders all of them irrelevant. You can't seize a Solana wallet. You can't issue a takedown notice to a decentralized ledger. The attacker's infrastructure is as permanent as the blockchain itself.
Each of these assumptions failing independently would be significant. All three failing simultaneously, in a single campaign that has been actively iterating for five months, represents a structural shift in supply chain risk.
The Registry Problem Nobody Wants to Fix
There's a fourth failure that the GlassWorm coverage has largely avoided: the registries themselves.
GlassWorm has been active since at least October 2025. Socket identified 72 malicious Open VSX extensions uploaded since January 2026. Endor Labs found 88 malicious npm packages uploaded through 50 disposable accounts. Five months of active exploitation, and the same techniques are still working on the same platforms.
The attackers evolved their approach during this period. Socket found that newer extensions abuse extensionPack and extensionDependencies in package.json, turning initially benign-looking extensions into transitive delivery vehicles in later updates. An extension you installed months ago for legitimate purposes can become malicious in a patch version, and VS Code auto-updates it silently without any interaction from you.
This isn't a novel attack pattern. It's the same supply chain trust model failure that has plagued package registries for years, now weaponized at a scale that makes manual detection impossible. The registries are relying entirely on third-party security companies like Koi, Socket, and Aikido to detect threats after publication rather than implementing meaningful pre-publication scanning.
What This Means for Your Security Posture
GlassWorm isn't a theoretical exercise. It's an active campaign that's been running for five months and escalating. If your developers use VS Code extensions, npm packages, or pull from GitHub repositories, your attack surface includes this threat.
Scan for invisible characters now. Tools like Aikido Safe Chain and the anti-trojan-source scanner can detect Unicode Private Use Area characters in codebases. Add this to your CI/CD pipeline. It takes minutes to implement and catches an entire class of attacks that human review cannot.
Audit your extension inventory. Know which VS Code and IDE extensions are installed across your development team. Remove anything you don't explicitly need. Disable auto-updates for extensions and review changelogs before updating. The IDE is a privileged access workstation; treat its extension ecosystem with the same scrutiny you'd apply to any other software supply chain.
Rotate developer credentials proactively. NPM tokens, GitHub personal access tokens, and registry credentials should be rotated regularly and scoped to minimum required permissions. GlassWorm's self-propagation mechanism depends on long-lived, broadly scoped credentials. Limiting token scope limits blast radius.
Monitor for behavioral anomalies, not just code changes. If code review can't catch invisible payloads, detection has to move downstream. Monitor for unexpected network connections from developer workstations, unusual package publishing activity, and credential usage patterns that don't match normal workflows.
The open-source trust model was built for a world where code is visible and commits are written by humans. GlassWorm operates in a world where neither assumption holds. The security controls have to evolve to match, and the gap between where they are and where they need to be is measured in the 35,800 developer installations that are already compromised.
