The danger in the code came from characters that are invisible to the human eye. In early March researchers at several security firms examined what looked like empty space and found hidden Unicode characters that decoded into a malicious program. Investigators soon traced hundreds of compromised open-source components spread across GitHub, npm and other major developer platforms to a cybercrime campaign known as GlassWorm that has been ongoing for months.
GlassWorm attacks some foundational assumptions of modern software development: that code you can read is code you can trust, that shared infrastructure is safe by default and that the people who maintain open-source projects can reliably catch what’s wrong before it ships. Because today’s applications are assembled from borrowed code, one poisoned package can spread far beyond the project where it first appeared.
Justin Cappos, a professor of computer science at New York University, who studies software supply-chain security, likens the attack to a typewriter hiding a second message in plain sight. “Imagine if, instead of just printing the character in black ink, maybe it used different amounts of blue and red and green ink in a really subtle way,” he says. “So it looked kind of black, but it wasn’t quite black. A human looking at something like this isn’t going to spot anything because the extra information is hidden.”
If you’re enjoying this article, consider supporting our award-winning journalism by subscribing. By purchasing a subscription you are helping to ensure the future of impactful stories about the discoveries and ideas shaping our world today.
The idea of weaponizing invisible characters isn’t new. In 2021 researchers at the University of Cambridge identified a class of attacks they called “Trojan Source,” which exploited Unicode, the standard that computers use to represent text and symbols. They warned that “downstream software will likely inherit the vulnerability.”
GlassWorm works in a similar way. Attackers submit what appear to be small fixes to open-source software. The changes look consistent with the surrounding code but contain invisible characters. “Typically, one line at the bottom says, ‘Hey, look through the file itself and pull out all the hidden information and do something sneaky with it,’” Cappos says.
What makes the GlassWorm campaign potent is the way it exploits software’s dependency structure. “Let’s say you wanted to make a web browser,” Cappos says. “You don’t want to have to write the code to display an image yourself.” Instead applications rely on libraries of prewritten code, which in turn automatically import dozens more. Any one of them can be poisoned. “The attacker will use the malicious software not to put malware in the program they’ve compromised but to say, ‘Hey, in order for me to work, I need some building block from over here,’” Cappos explains. “And that building block is the one that has the malware.”
The March 2026 wave was notable for both scale and sophistication. Between March 3 and March 9, cybersecurity companies Aikido, StepSecurity and Socket traced GlassWorm activity across hundreds of repositories and extensions. The infections spanned JavaScript, TypeScript and Python repositories. And by March 16, two previously clean packages with roughly 135,000 monthly downloads had been infected.
The attackers behind GlassWorm are in it for the money. Once the hidden code runs, it downloads secondary scripts designed to steal cryptocurrency tokens, developer credentials and other secrets. “These often are professional cybercriminal gangs,” Cappos says. “They’re making tons of money.”
Their success exposes a deeper problem. The field of software supply-chain security has been, in Cappos’s view, “very much overlooked for a long period of time.” Nation-state actors have exploited it for more than a decade, he says, and now cybercriminals have woken up to the opportunity. But the real failure, he argues, is not careless maintainers of open-source code—it’s inadequate security tools. “I think the really easy thing to do is to try to blame the maintainers, but that’s a bit shortsighted,” he says. “Tooling and security protections need to get better to save us.”
