An npm worm first written off as a harmless test turns out to have armed 42 genuine GitHub repositories with payloads too large for GitHub’s own search to see. Developers did not need to install anything: opening one of the repositories in an AI coding assistant or VS Code was enough to run it.
What happened
On 26 October 2026 JFrog Security Research published its analysis of the “testmetest” npm campaign. Researchers Guy Korolevski and Yair Benamou found 42 armed repositories belonging to 11 legitimate GitHub owners, and every one of them carried a hidden publishing payload for the worm. JFrog’s own tooling had flagged the npm side of the activity on 21 October.
Supply chain specialist SafeDep raised the alarm first. It linked 18 npm packages to a single operator, all released between 19 and 25 October. On 22 October, though, SafeDep said it had found no third-party victims and wrote that “All observed activity belongs to the operator’s own test accounts”. JFrog’s sweep showed that view was wrong. Some account takeovers went back to July, a scripted wave of repository arming followed on 28 September, and the operation was still running through October from an attacker account called CementBeetleSteeple, which hosted 17 campaign repositories.
One victim was a 2013-vintage Argentine developer account with years of genuine history. Nothing in the research points to a breach of GitHub’s platform itself; hijacked accounts and stolen credentials appear to have been the way in.
The technical picture
Size as camouflage. Each victim repository holds a polymorphic wrapper of roughly 12.9 to 13.7MB. GitHub code search does not index blobs that large, and the contents API will not serve them. A search for known indicators found the hook files in 26 repositories, but the payloads looked empty. JFrog describes payloads built “to evade the GitHub search and API paths” hunters normally use, and reached the full 42 only by walking git trees. Ten different wrapper builds all decode to the same payload of about 2MB.
Open the folder, run the code. The victim repositories contain configuration files for Claude Code, Gemini, Cursor and VS Code that launch a script under the .github directory as soon as a session starts or the folder is opened. Supply chain defences have long focused on install-time hooks; here, cloning a repository and pointing an AI assistant at it is enough.
Abusing trusted publishing. Short-lived branches with names like chore/ci-<hex> carried a script that ran inside GitHub Actions. It obtained an OIDC token scoped to npm, exchanged it for a publishing credential and pushed tampered package versions. A fake CodeQL workflow dumped the runner environment, npm tokens included, into a short-lived artifact. JFrog recovered 29 of these artifacts, three of which held real-format npm tokens.
A native addon variant keeps its real payload in an encrypted cache file and declines to run on CI runners, in containers, on small virtual machines or under a debugger; the Windows build also watches for common analysis tools. The operator made the commit history look older than it was by copying author dates from legitimate commits and adding a skip-checks marker so CI would not run on those pushes. An attacker-owned repository that JFrog describes as a live data sink held 27 encrypted snapshot files by 25 October.
The worm also has a destructive streak. According to The Register’s reporting of the research, it carries a wiper that deletes the victim’s home directory when the stolen GitHub token is revoked, a trick borrowed from the earlier Mini Shai-Hulud worm. SafeDep tied the code to the Miasma family, but both firms say its lineage is uncertain, and JFrog does not claim the original Miasma operators are behind it.
Why it matters for UK organisations
None of the published research names a UK victim, and JFrog only identifies some of the 11 owners. That should not be read as an all-clear. UK software houses, fintechs and public sector digital teams depend on npm and GitHub, and many have adopted AI coding assistants quickly. A developer cloning a repository to evaluate it is exactly the target.
The credential reach is the bigger worry. Developer laptops and CI runners commonly hold GitHub, npm, cloud, SSH and AI provider keys. Once those are taken, the worm publishes under a trusted maintainer’s name, so downstream consumers inherit the compromise. For organisations within scope of the Cyber Security and Resilience Bill, and for managed service providers in particular, that is a direct supply chain risk. It is also the kind of incident the NCSC’s software security code of practice expects vendors to be able to detect and contain.
Expert view
When we run red team engagements against engineering teams, developer workstations and CI pipelines are usually the softest high-value target in the estate. This campaign shows attackers have worked that out too. Hiding a payload in a file too large to index is crude but effective: it defeats the first hunting method most of us reach for, searching for the indicator and moving on when nothing comes back.
The AI assistant angle is the more important lesson. Editor and agent configuration files now behave like executable code, yet most code review processes treat a change to .vscode or .claude settings as harmless housekeeping. In my experience reviewers skim past dot-directories almost entirely, and that needs fixing in policy, not just habit.
The token revocation wiper also flips standard incident response on its head. The usual instinct is to revoke compromised credentials immediately. Here, doing that before you have cleaned the host can destroy the evidence and the developer’s working data. Sequencing matters, and responders need to know about it before they start.
What to do now
- Check exposure. Search lockfiles and package caches for any “testmetest” package or the other names in JFrog’s indicator list. Treat any machine that installed a full worm version as compromised and rebuild it from known-good media.
- Clean before you revoke. Strip out the worm’s persistence services (net-health-checker, pkg-runtime) first. Only then rotate every GitHub, npm, cloud, SSH and AI key the affected user or runner could reach.
- Hunt properly. Enumerate repository git trees through the API rather than relying on code search. Look for unexpected chore/ci-* and deps/upd-* branches, skip-checks commits, scan-output artifacts and recently added assistant configuration files.
- Treat assistant config as code. Use CODEOWNERS and branch protection so changes to .claude, .gemini, .cursor and .vscode files need review. Keep editor workspace trust switched on and disable automatic task execution (Cyber Essentials: secure configuration).
- Tighten publishing. Restrict which workflows and branches can request npm OIDC tokens, require approval for workflow runs from new branches, and keep long-lived publishing tokens off CI (Cyber Essentials: user access control).
- Contain unknown code. Open third-party repositories in disposable, credential-free environments rather than on a laptop holding production keys (Cyber Essentials: malware protection).
Bottom line
This campaign was dismissed as a test and turned out to be live. Its operator used file size to blind search and AI tooling to make simply opening a repository dangerous. UK teams should hunt by walking their git trees rather than trusting search, review assistant configuration files as carefully as code, and clean infected machines before revoking tokens.
Sources
- JFrog Security Research: Beyond testmetest: Native Addon Camouflage and 42 Armed GitHub Repositories Reveal a Hidden npm Publisher
- The Register: Worm armed 42 GitHub repos by hiding a payload too big to fail
- InfoWorld: Attackers compromised 42 GitHub repositories by using files too large to be searched
- Cyber Security News: Hackers Hijack 42 GitHub Repositories to Plant Malware Traps for Claude, Gemini, and Cursor Users
