Glassworm Campaign Hides Malware in Blank Unicode GitHub Commits

On March 13, 2026, Aikido Security disclosed a new Glassworm supply-chain wave that used invisible Unicode characters to hide JavaScript malware in GitHub commits, npm packages, and a VS Code extension. The campaign affected at least 151 GitHub repositories between March 3 and March 9, plus named malicious releases on npm and the VS Code marketplace. For developers, the practical point is simple: a commit can now look visually blank while still containing executable payloads.

The technique matters because it targets a real review habit. Maintainers scan diffs, skim small refactors, and approve plausible edits. Glassworm paired a hidden Unicode payload with project-specific, legitimate-looking commit changes, which Aikido says were likely produced at a scale that suggests LLM assistance.

The Disclosure

Aikido’s March 13 write-up describes a fresh March 2026 resurgence of the Glassworm campaign, a malware family previously observed in 2025 across npm, Open VSX, and GitHub. In this wave, the attacker hid code in what appeared to be empty strings, then used a visible decoder stub to reconstruct and execute the real payload at runtime.

Aikido found 151+ matching GitHub repositories using a search pattern for the Unicode decoder stub, and said that total is likely low because some repos had already been removed by the time of publication.

Known affected artifacts in this March 2026 wave

Ecosystem	Affected item	Version(s) / count
GitHub	Matching compromised repositories	151+
npm	@aifabrix/miso-client	4.7.2
npm	@iflow-mcp/watercrawl-watercrawl-mcp	1.3.0 - 1.3.4
VS Code Marketplace	quartz.quartz-markdown-editor	0.3.0

Aikido also named several compromised repositories, including pedronauck/reworm with 1,460 stars, pedronauck/spacefold with 62 stars, and anomalyco/opencode-bench with 56 stars. This was not limited to low-visibility throwaway repos. The trust signal came from recognizable projects and org-owned repositories.

How the hidden payload works

The visible malware pattern is short. A JavaScript stub maps Unicode code points from ranges such as U+FE00-U+FE0F and U+E0100-U+E01EF into bytes, then decodes and runs them with:

eval(Buffer.from(...).toString('utf-8'))

The critical trick is the input string. It appears empty or blank in normal review views, but it actually contains the hidden payload encoded in non-rendering Unicode characters.

Visible structure vs actual behavior

What a reviewer sees	What the code does
Small JavaScript helper	Maps hidden Unicode code points into byte values
Apparently empty template string	Contains the concealed second-stage payload
Buffer.from(...).toString('utf-8')	Reconstructs the hidden script
eval(...)	Executes the decoded malware

That places this incident in the same broad family as Trojan Source style attacks, where source code’s meaning diverges from what the reviewer perceives. In this case, the divergence is operational rather than purely syntactic. The code path is explicit, but the payload source is visually concealed.

Operational Scale and LLM-Assisted Tailoring

The Unicode trick itself is established. The operational scale in this March 2026 wave is the bigger development.

Aikido’s analysis says the commits were wrapped in plausible, project-specific edits, including docs updates, version bumps, bug fixes, and small refactors styled to fit each repository. At 151+ bespoke-looking changes, the campaign appears optimized for reviewer trust rather than only technical obfuscation.

That is where AI enters the story. Aikido presents LLM assistance as the most plausible explanation for the volume and per-project tailoring, while stopping short of claiming proof. That distinction matters. The news here is not that an AI system autonomously compromised GitHub. The news is that invisible payloads and convincing cover commits now fit together at a scale that manual social engineering rarely reached.

If you rely on AI tools in development, this intersects directly with your workflow. Teams increasingly use assistants for patch review, commit summarization, and change triage. A visually benign diff becomes more dangerous when human and machine reviewers both prioritize surface coherence. This is adjacent to the risks covered in How to Use AI for Code Review and the broader workflow issues in The AI Coding Workflow That Actually Works.

Scope across ecosystems

Glassworm’s March 2026 wave crossed three software distribution channels at once.

Channel	March 2026 activity
GitHub	Compromised commits in 151+ repositories
npm	Malicious package versions published under named packages
VS Code Marketplace	Malicious extension version published

That cross-ecosystem spread is what makes this a supply-chain event rather than a repository hygiene issue. A compromised repo can feed package releases. A compromised package can land in CI or developer laptops. A compromised editor extension can expand collection points for credentials and tokens.

Aikido says prior related samples decoded a second stage that used Solana as a delivery channel and stole tokens, credentials, and secrets. The March 2026 wave is consistent with that same actor behavior.

GitHub already had a mitigation, and it was not enough

GitHub added a hidden Unicode warning on May 1, 2025, flagging files that contain concealed Unicode text. GitHub also noted that such content can make code appear one way in the UI while being interpreted another way, and recommended reviewing these files in editors like VS Code, which highlight hidden Unicode by default.

That context is important because it sharpens the analysis. Detection features existed before this March 2026 wave. The campaign still landed across at least 151 repositories.

What that implies

Observation	Practical reading
GitHub shipped hidden Unicode warnings in 2025	Platform-level detection is available in some review paths
Glassworm still compromised 151+ repos in March 2026	Detection is not consistently changing reviewer behavior
Commits looked legitimate beyond the payload stub	Social trust remains the weak point
Hidden text spans repos, packages, and extensions	Defense has to cover publishing pipelines, not only pull requests

For AI engineers, this is the same pattern seen elsewhere in tooling security. A warning in one interface does not solve a workflow problem across IDEs, bots, package release jobs, and automated merge paths. The operational lesson resembles the one behind What Google’s $32B Wiz Acquisition Means for Multicloud and AI Security: visibility matters, but control points matter more.

How this differs from the other March GitHub malware story

Aikido explicitly says this campaign is separate from PolinRider, another March 2026 GitHub compromise wave. That distinction matters for defenders. March had multiple active repository compromise stories, and Glassworm’s signature is specifically Unicode-hidden payloads plus a decoder stub.

If you are triaging suspicious commits from the March 3-9, 2026 window, treat Glassworm hunting as its own track:

• search for suspicious Unicode ranges in JavaScript and TypeScript files
• flag eval(Buffer.from(...).toString('utf-8')) patterns
• review commits that pair innocuous edits with tiny executable stubs
• inspect package and extension releases that align with repo compromise windows

This is especially relevant if you build tooling around MCP servers, package-based agent integrations, or editor plugins. A malicious package or extension can become an attack path into local developer context, secrets, and automation. If your stack depends on these interfaces, review What Is the Model Context Protocol (MCP)? as infrastructure, not just developer ergonomics.

Recommended Actions

First, audit the March 3-9 window. If you maintain JavaScript, TypeScript, npm, or VS Code-related projects, review commits and releases made during that period. Start with external contributor commits, unusual maintainer account activity, and small “cleanup” changes that introduced decode-and-execute logic.

Second, add Unicode-aware scanning to CI. Grep for the relevant code point ranges, reject hidden Unicode in executable files by default, and require explicit override for legitimate use cases. Visual review is insufficient for this class of malware.

Third, block obvious runtime decode patterns. eval, dynamic Function, and decode pipelines from non-printing characters should trigger manual review. The presence of eval(Buffer.from(...).toString('utf-8')) is a strong signal.

Fourth, inspect downstream artifacts, not just source. Check published npm versions, extension packages, generated bundles, and release tags. Glassworm crossed repo, package, and extension boundaries in the same wave.

Fifth, harden AI-assisted review. If you use coding assistants or automated review agents, include checks for hidden Unicode and suspicious decode stubs in the prompt, policy, or post-processing layer. This is part of context engineering, where the system needs explicit instructions about what to inspect in code and diffs. The workflow issue is closely related to Context Engineering: The Most Important AI Skill in 2026 and the tradeoffs in Best AI Coding Assistants Compared (2026): Cursor vs Copilot vs Windsurf.

If you maintain open source packages or internal developer tooling, treat hidden Unicode as a release-blocking condition in executable code. Then test that policy against the exact Glassworm decoder pattern, not just generic lint rules.