The New Supply Chain Trick Is Code You Literally Cannot See

The nastiest part of this supply chain attack is not the payload. It is the presentation.

Aikido Security says attackers uploaded 151 malicious packages to GitHub between March 3 and March 9, 2026. The trick was hiding the payload inside invisible Unicode characters from Private Use Areas — specifically codepoints 0xFE00–0xFE0F and 0xE0100–0xE01EF — so the malicious block rendered as what looked like empty space.

Open the file in an editor, terminal, or review UI and you see nothing. Run a typical code review pass and you still see nothing. Most static analysis tooling sees whitespace too. At runtime, though, a compact JavaScript decoder pulls those hidden bytes back out and hands them to eval().

That is the novelty here: not obfuscation in the usual sense, but malware that survives inspection by pretending to be blankness.

Blank on screen, active at runtime

This attack works because the code is not visually disguised. It is visually absent.

The attacker stores byte values inside invisible Unicode characters, then ships a tiny decoder that reconstructs the hidden script when the package runs. According to the reporting, the decoded payload then fetched second-stage scripts using Solana as a delivery channel and went after tokens, credentials, and other secrets.

Developers are used to suspicious code looking suspicious: long encoded blobs, weird variable names, giant compressed strings, bizarre control flow, or a dependency tree that feels off. This one breaks that instinct. The malicious section can sit inside a file as a blank-looking string that reads like formatting noise.

That has ugly implications for both humans and AI tools. A reviewer can stare directly at the compromised line and miss it because there is nothing visible to inspect. Claude Code and similar coding agents would likely miss it for the same reason: they reason over visible code, and the visible code is a blank string.

An old Unicode trick just crossed into mainstream malware

Invisible Unicode abuse is not new as an idea. Variants of the technique were devised decades ago, then resurfaced in 2024 in the context of AI prompt injection. What changed is the venue.

It has now migrated into ordinary supply chain malware — packages developers install, extensions developers trust, repositories developers skim before they pull.

That shift matters more than the Unicode trivia. Once a technique leaves the research-and-weird-edge-cases bucket and starts showing up in package ecosystems, it becomes operational. Teams need to assume copycats will simplify it, automate it, and port it anywhere code can be pasted.

Aikido's 151-package count is almost certainly not the full set. Many packages were deleted before researchers could catalog them, and similar malicious packages have since been found on npm and in the VS Code marketplace. The visible number is best read as a floor, not a total.

The other story inside the story: AI is likely doing the scaling

The most unsettling detail may be the production tempo.

Researchers suspect AI is generating the packages at scale. That call is not hype. It is a practical observation: 151 bespoke code changes across different projects in one week is not a normal human throughput problem. It looks like an attacker found a generation loop that can adapt payload wrappers to many targets faster than defenders can review them.

This is the inversion a lot of the market still misses. We talk constantly about AI-assisted development: faster scaffolding, better autocomplete, easier refactors, more code shipped by smaller teams. The same machinery can industrialize malware packaging. If defenders use models to write cleaner integration code, attackers can use models to produce endless variations that dodge simple signatures.

And this attack has a nasty cultural fit. It preys on developers who add packages quickly, trust appearances, and assume a fast skim is a review. Call it the dark side of vibe coding: if your trust model is "looks fine," invisible code wins by default.

Three checks worth adding before your next install

A long policy memo is not the answer here. A few concrete habits are.

1. Inspect dependency code before adding it

Not every package deserves a forensic teardown, but new or obscure packages deserve more than a glance. Check the maintainer, the publish pattern, the repository history, and whether the code contains decoder logic that reconstructs strings or bytes at runtime.

2. Treat decoder patterns plus eval() as a flare, not a curiosity

A tiny routine that walks characters, extracts numeric values, rebuilds a payload, and passes the result into eval() is not normal library behavior. Even if the visible source looks sparse or blank, the presence of a decoder path is the real signal.

3. Audit VS Code extensions like you audit packages

The fact that similar samples appeared in the VS Code marketplace matters. Extensions get broad access to source code, tokens, and developer workflows. Plenty of teams scrutinize production dependencies and then install editor extensions with almost no review. That gap is wide open now.

Where careful teams still have an edge

This attack is clever, but it is not magic. It depends on speed, trust, and shallow inspection. The teams that slow down just enough to verify new dependencies, flag unusual decoder behavior, and review editor extensions as part of their security surface are still in a much better position than the teams treating every install as harmless plumbing.

The verdict is simple: invisible code changes the ergonomics of review, not the fundamentals of defense. If a package needs blank-looking strings, a decoder, and eval() to run, it has already told you more than enough.