From Tokyo: The developer's instinct is to trust what they see. A pull request that looks clean, a version bump that seems routine, a small refactor that reads naturally within the project's style. These visual cues have been the foundation of open-source security for decades. But what if the attack is designed to be completely invisible?
Researchers at Aikido Security reported on Friday that they had found at least 151 GitHub repositories compromised by a threat actor tracked as Glassworm, which hides malicious payloads in Unicode characters invisible to the human eye. The campaign represents a watershed moment in software supply chain attacks: for the first time, attackers have weaponised a technique that breaks the fundamental assumption underlying code review itself.
The technique exploits Unicode Private Use Area characters, specifically ranges 0xFE00 through 0xFE0F and 0xE0100 through 0xE01EF, which render as zero-width whitespace in virtually every code editor and terminal. When a developer reviews a pull request, they see nothing. The malicious code is simply not there, from their perspective. Meanwhile, a small decoder extracts the hidden bytes and passes them to eval(), executing a full malicious payload.
The scope is alarming. A GitHub code search for the decoder pattern currently returns at least 151 matching repositories, and that number understates the true scope, since many affected repositories have already been deleted by the time of writing. The affected repositories were compromised between March 3 and March 9, according to the Aikido Security blog, and the campaign has since expanded to npm and the VS Code marketplace.
What makes Glassworm particularly dangerous is its sophistication. Instead of showing up as obviously suspicious commits, they're taking the form of version bumps and small refactors that are "stylistically consistent with each target project." Aikido says it suspects the attackers are using large language models to generate this cover, since manually creating 151 bespoke code changes across different codebases wouldn't be feasible otherwise.
The Blockchain Fallback
In past Glassworm incidents, that payload fetched and executed a second-stage script that used the Solana blockchain as a command-and-control channel, capable of stealing tokens, credentials, and secrets. This choice of infrastructure reveals a strategic adaptation to modern security defences. Traditional command servers can be taken down. Blockchain transactions cannot. 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.
An earlier investigation by Koi Security found the group used stolen npm, GitHub, and Git credentials to propagate the worm further, with decoded payloads deploying hidden VNC servers and SOCKS proxies for remote access.
The threat extends beyond credential theft. The malware specifically targets and drains funds from 49 different cryptocurrency wallet extensions, including popular ones like Coinbase Wallet, MetaMask, and Phantom. The worm becomes self-propagating: steal credentials, use them to compromise more repositories, extract more credentials, spread further.
Why Visual Review Fails
The implications challenge a foundational belief in software security. Code review has long been treated as a primary line of defence against supply chain attacks. Talented engineers reading code, catching bugs, spotting malicious logic. But that defence assumes the reviewer sees what the compiler sees. Glassworm shatters that assumption.
Aikido recommends scrutinising package names and dependencies before incorporating them into projects, and using automated tooling that scans specifically for invisible Unicode characters, since visual code review doesn't protect this class of injection. The word "doesn't" is significant. It is not a weakness of human attention. It is a failure of the entire model.
For Australian developers and organisations relying on open-source components, the risk is immediate. Among the affected repositories are some notable names: a repo from Wasmer, Reworm, and opencode-bench from anomalyco, the organisation behind OpenCode and SST. Any project depending on these repositories may have inherited the malicious code. Discovering it requires not human eyes, but machine scanning.
The incident also exposes a troubling timeline. Glassworm has been active since at least March 2025, when Aikido first found the invisible Unicode technique in malicious npm packages. Nearly a year of successful attacks suggests the problem is not new, but newly visible. How many compromises went undetected before researchers developed the tools to find them?
Moving Forward
The question facing the development community is not whether to adopt new defences, but how quickly. Do not trust "it looks fine" and don't assume your tooling automatically shows invisible characters; instead, you should proactively scan for them. We recommend you scan all code before merging pull requests. This is labour-intensive if done manually. It is essential if attacks are now invisible.
The technical solution exists: scanning tools like anti-trojan-source can detect the dangerous character ranges. Major platforms are responding: Open VSX team take malware and supply-chain risk seriously. We are actively strengthening our pre-publishing safeguards, including automated checks designed to detect and block known malicious patterns before an extension is published.
But technology alone will not solve this. The attack exploits not a software bug but a feature of the Unicode standard itself, which allows invisible characters by design. What has changed is the willingness of attackers to use it. That change persists. Every developer, every organisation, every extension publisher now operates in an environment where the invisible has become a real threat. Trust what you can see, the old advice ran. That advice no longer works.