Glassworm Is Back: Invisible Code Is Hiding Inside 151+ Open-Source Repositories

The code looks clean. The commit message is professional. The diff shows a minor documentation fix, maybe a version bump, perhaps a small refactor. A senior engineer reviews it, sees nothing suspicious, and merges it. Somewhere inside that commit, invisible to every tool they used, is a complete malicious payload - a piece of JavaScript waiting to execute and begin stealing credentials, tokens, and secrets.

This is how Glassworm operates. And this month, the threat actor behind this technique has scaled up dramatically. Security researchers at Aikido Security reported on March 13, 2026 that a new mass campaign has compromised at least 151 GitHub repositories, with simultaneous infections spreading to npm packages and VS Code extensions - making it the group's most ambitious and coordinated operation since they were first discovered a year ago.

The attack is not theoretical. The repos hit include projects with hundreds to thousands of stars. The infected packages were being actively downloaded. And the technique exploits a blind spot so fundamental to how developer tools work that most organizations have no existing defense against it.

What Glassworm Actually Does

To understand why this attack is so dangerous, you need to understand what Unicode is and why it has a soft underbelly that attackers have learned to exploit.

Unicode is the global standard for encoding text in computers. It covers every character in every human writing system, plus thousands of special-purpose symbols. Among those special characters are variation selectors - code points in the ranges U+FE00 to U+FE0F, and U+E0100 to U+E01EF - originally designed to specify alternate display forms of emoji and other symbols.

Here is the problem: variation selectors are invisible. They have no glyph. Editors do not render them. Terminals display nothing. Code review interfaces show a blank space. Git diffs show nothing. And they are completely valid Unicode, so parsers do not complain about them either.

Glassworm discovered that these invisible characters can be used as a binary encoding scheme. By carefully selecting sequences of variation selectors, you can encode arbitrary bytes as a string of characters that occupies real memory, executes in JavaScript, but appears to every human-visible tool as an empty string.

The actual decoder injected into target code looks like this:

The backtick string passed to the function s() looks completely empty to any human reviewer. But at runtime, the JavaScript engine processes those invisible characters, the decoder extracts real bytes, and eval() executes whatever the attacker embedded. In previous Glassworm incidents, Aikido confirmed that the decoded payload fetched and ran a second-stage script using Solana as a covert delivery channel - capable of stealing wallet tokens, API credentials, environment variables, and session secrets.

The attack bypasses almost every standard defense because those defenses are designed to look for recognizable patterns. SAST tools parse syntax. Linters check style. Human reviewers read code. None of them can read what they cannot see.

A Year in the Making

Glassworm did not arrive in March 2026 fully formed. Security researchers at Aikido have been tracking this threat actor for over a year, watching them refine and expand their technique across different parts of the open-source ecosystem.

This trajectory tells a clear story. Glassworm began as a proof of concept attack in a corner of the npm registry. Over twelve months they tested, refined, and expanded their operation - and each time researchers documented their methods, they pivoted rather than stopped. The March 2026 wave is not a repeat of prior attacks. It is an escalation.

The March 2026 Wave: Scale and Targets

The scope of the current campaign is significant enough to treat as a category-one supply chain incident. According to Aikido's analysis, a GitHub code search for the characteristic decoder pattern currently returns over 151 matching repositories. That number understates the real impact - many affected repositories had already been deleted by their owners before the analysis was published, meaning the actual number of compromises is higher.

The compromises are not random. Among the confirmed affected repositories are several with meaningful download counts and community followings. pedronauck/reworm, a React data container library with 1,460 stars, was compromised. anomalyco/opencode-bench, the benchmark suite for the OpenCode AI coding agent from the SST team, was hit. Wasmer, the company building the WebAssembly runtime used in server-side environments, had an example repository compromised. A CSS plugin for the Docz documentation framework, with 39 stars, was also targeted.

On the npm side, researchers identified @aifabrix/miso-client (version 4.7.2, published March 12) and @iflow-mcp/watercrawl-watercrawl-mcp (versions 1.3.0 through 1.3.4, also March 12). In the VS Code marketplace, the quartz.quartz-markdown-editor extension (version 0.3.0, March 12) was found to contain the injection. The simultaneous publication dates across multiple ecosystems on March 12 are a strong indicator of coordinated, automated deployment.

AI-Assisted Camouflage: The Human Side of Glassworm

One detail in Aikido's analysis deserves particular attention. The malicious injections did not arrive in obviously suspicious commits. The surrounding changes - the context around where the invisible payload was inserted - were stylistically realistic. Documentation tweaks. Version bumps. Small bug fixes written in a style consistent with the target project's history.

Aikido researchers concluded that this level of project-specific tailoring almost certainly requires large language models to generate convincing cover commits. At the scale we are seeing - 151 or more distinct repositories across multiple languages, frameworks, and coding styles - manual crafting of bespoke cover commits is not feasible. The evidence points to an attacker using AI coding tools to automatically generate contextually appropriate cover stories for each individual repository before injecting the invisible payload.

This is a significant development in the threat landscape. Supply chain attackers have historically relied on typosquatting (publishing packages with names close to popular ones), dependency confusion (exploiting how package managers resolve names), or direct credential theft to compromise repositories. Glassworm's approach is different: they are exploiting a perceptual blind spot in how humans review code, then using AI to make sure nothing around that blind spot looks suspicious.

"Even after months of coverage, it continues to catch developers and tooling off guard. Invisible threats require active defenses. You cannot rely on visual code review or standard linting to catch what you cannot see." - Aikido Security research team, March 13, 2026

This represents a qualitative shift from attacker-as-opportunist to attacker-as-sophisticated-operator. The original Glassworm technique required understanding Unicode internals and JavaScript runtime behavior. The current campaign requires automating that technique at scale with AI-assisted social engineering layered on top. That is a meaningfully more capable adversary than what defenders were tracking in early 2025.

Why Standard Defenses Fail

The core problem is that virtually every layer of standard software security review was built to detect threats that humans can see. Let that sink in.

Static analysis tools - SAST scanners, linters, formatters - operate on the parsed representation of code. They look for suspicious patterns: calls to eval(), network requests to unusual domains, access to environment variables. The Glassworm payload does call eval(), but the argument to eval() looks like an empty string. The parser does not know the string is full of invisible Unicode. By the time eval() executes, the analysis phase is over.

Human code review is even more obviously compromised. You review what you see. A human looking at a diff showing that a string literal went from empty to empty-looking does not register that as a change at all. The invisible characters are real bytes taking up real space in the file, but the reviewer's display renders nothing.

Version pinning helps only after the fact, once a compromise is identified and a known-good version is established. Dependency scanning relies on known CVEs or known malicious package hashes - Glassworm infections by definition have no prior CVE because the injections are custom-crafted per target.

Git signing provides some protection, but most repositories do not enforce mandatory signing on all commits, and the attacker is presumably able to commit as a legitimate contributor who has write access to the repo (or who has submitted a pull request that was merged without detecting the payload).

What is actually required is scanning that specifically looks for invisible Unicode characters in code locations where they should not exist - a behavior-aware check rather than a pattern-aware one. Aikido has built this detection into their malware scanning pipeline and reports that it flags the Glassworm pattern as a 100/100 critical finding. Their open-source tool Aikido Safe Chain, which wraps npm, npx, yarn, pnpm, and pnpx, also integrates this detection at the point of package installation.

The Broader Context: Open Source Trust Is Infrastructure

The Glassworm campaign is not happening in isolation. March 2026 has seen simultaneous reporting on PolinRider, a separate campaign also compromising hundreds of GitHub repositories through different means. Security researchers at Aikido noted that while PolinRider was making headlines, Glassworm was running a parallel operation that received less attention - which may have been deliberate.

The software supply chain has become one of the primary attack surfaces in modern cybersecurity, and the trend is accelerating. The SolarWinds compromise of 2020, the Log4Shell vulnerability in 2021, the XZ Utils backdoor discovered in 2024 - each demonstrated that attackers who successfully embed themselves in widely-used open-source code gain access to downstream systems at a scale no direct attack could match. A single compromised library used by thousands of projects represents a multiplier effect that is almost impossible to replicate through any other attack vector.

What Glassworm adds to this picture is the weaponization of human perceptual limitations. Previous supply chain attacks generally required either finding an existing vulnerability, gaining legitimate access through social engineering over time, or exploiting naming collisions. Glassworm's technique requires none of those - just the ability to inject bytes into a file that will never be detected by visual inspection.

This matters for the open-source model itself. The collaborative code review process that gives open source much of its security credibility - the idea that many eyes make bugs shallow - assumes that reviewers can see what they are reviewing. Glassworm is a direct attack on that assumption. If invisible payloads can slip through community review processes undetected for days or weeks, the security benefits of open collaboration are being undermined at their foundation.

Second-Order Effects: What This Changes

The immediate threat - infected repositories, potentially compromised developers who installed affected packages - will be cleaned up. GitHub will remove compromised code. npm will yank the malicious package versions. VS Code will pull the infected extension. That is the short game, and it is already underway.

The longer game is more concerning. Glassworm has now demonstrated that invisible Unicode supply chain attacks work at scale across multiple ecosystems simultaneously. That demonstration is visible to every other threat actor monitoring the space.

Security researchers and defenders will rightly point to the fact that Aikido built detection for this. But most organizations do not use Aikido. Most package installation workflows do not include invisible Unicode scanning. And the attackers, as they have shown repeatedly over the past year, are willing and able to modify their approach when a specific detection method is developed.

There is also a secondary concern related to AI-assisted code generation. Glassworm appears to be using LLMs to write realistic cover commits. Developers using AI coding assistants are increasingly working with code they did not write themselves and may not fully understand at a bytecode level. If an AI assistant suggests a change that contains invisible Unicode, will the developer notice? Current AI coding tools have no mechanism to flag or sanitize non-printable characters embedded in code they generate or suggest.

The DHS's recent struggles with basic contract renewals - including the lapse of a tornado tracking tool contract that left rescuers without critical data last weekend - are a useful reminder that defensive infrastructure requires active maintenance and funding. The same principle applies to open-source security tooling. Detection exists for the Glassworm technique. Making that detection ubiquitous requires investment, integration, and attention that the current threat landscape does not guarantee.

What Developers and Organizations Should Do Right Now

The practical response to Glassworm is less complicated than the threat itself, but it requires proactive action rather than waiting for your existing toolchain to catch something it is not designed to catch.

First, audit any repository that merged external contributions between March 3 and March 9, 2026. That is the confirmed attack window for the current wave. If you merged a pull request from an external contributor or noticed a commit that looked like a small, innocuous change during that period, run a Unicode character audit on the modified files.

The easiest manual check is a hex scan for the FE00 byte range, which corresponds to variation selectors in UTF-8 encoding:

Second, add invisible Unicode detection to your CI/CD pipeline as a mandatory gate. A simple grep or Python script checking for variation selector byte ranges in committed code files costs essentially nothing to run and would catch Glassworm-style injections before they merge.

Third, if you maintain a VS Code extension or publish npm packages, review your publication pipeline for unauthorized versions. The March 12 npm publications and VS Code extension were likely the result of compromised package maintainer credentials, not just repository tampering.

Fourth, configure your code editor to display invisible characters explicitly. VS Code has a setting (editor.renderControlCharacters and related Unicode highlighting options) that can be configured to visually flag non-standard Unicode in source files. It will not catch everything, but it introduces a visible signal where there was none before.

The Aikido Safe Chain tool, while vendor-produced, is open source and free. It functions as a wrapper around standard package managers that adds real-time malware scanning - including invisible Unicode detection - at the point of installation, which is exactly where this attack surface needs to be defended.

"A tool that can stop supply-chain malware in real time as they appear can prevent a serious infection. This is the idea behind Aikido Safe Chain." - Aikido Security, on their open-source defense tooling

Looking Forward: The Arms Race No One Signed Up For

The Glassworm story is about more than one threat actor running one clever attack. It is an illustration of a structural problem in how the open-source ecosystem handles trust at scale.

GitHub, npm, and the VS Code marketplace each have security teams and abuse detection systems. None of them caught this campaign before it affected hundreds of repositories across six days. That is not a criticism of their teams - it is a reflection of how difficult invisible-character attacks are to detect at scale without specific tooling purpose-built for the job.

The gap between detection capability and widespread deployment of that capability is the real vulnerability. Aikido has had invisible Unicode detection built since at least early 2026. The vast majority of developers and CI/CD pipelines do not run it. That gap - between what is technically possible and what is operationally deployed - is where supply chain attackers live.

The March 2026 Glassworm wave will recede. Compromised repositories will be cleaned. Package versions will be yanked. Some organizations will add Unicode auditing to their pipelines. But the technique will persist, and variants will emerge. Glassworm has demonstrated that invisible Unicode injection works at scale with AI assistance. That knowledge does not disappear, and the next actor to use it will have the benefit of prior art.

Open source won the software infrastructure war. The majority of critical software running the internet, cloud services, and enterprise systems depends on open-source components. That dependency is now a structural attack surface, and the adversaries targeting it are getting more capable, more automated, and more patient. The Glassworm campaign is a reminder that in the supply chain security arms race, defenders have to be right every time - and the attackers only have to find the code reviewers cannot see.