npm Worm Campaign Armed 42 GitHub Repos, JFrog Says

A worm campaign that security firms first saw as a handful of test packages on npm had already rigged real GitHub projects, according to new research from JFrog. In a report published on 26 October, its researchers say they found 42 “armed” repositories belonging to 11 legitimate owners, each set up so that simply opening the project in an AI coding assistant or code editor could run hidden code.

The finding changes the picture painted four days earlier. When SafeDep first documented the “testmetest” packages on 22 October, it said it had found no compromised third-party packages or victims, and that all the activity it could see belonged to the operator’s own test accounts.

In brief

JFrog says 42 real GitHub repositories from 11 legitimate owners were rigged to run hidden code when opened in Claude, Gemini, Cursor or VS Code.
The payload files were 12.9 to 13.7 MB, and GitHub code search did not index them; a first code-search sweep found 26 repositories.
SafeDep says the npm worm installs a wiper that deletes the home directory if the stolen GitHub token is revoked.
Remove the worm’s persistence before revoking tokens, JFrog advises.

How the npm packages work

SafeDep counted 18 packages published to npm from the same operator between 19 and 25 October. It says the malicious versions steal credentials, spread to other packages and repositories, and install a wiper that deletes the user’s home directory if the victim revokes the stolen GitHub token. It links the code to the “Miasma” family of npm worms but says it has not confirmed the exact lineage. JFrog likewise says its evidence shows shared tooling, not that the original Miasma operators are responsible.

On 26 October SafeDep added that the operator had moved to a third npm account and changed how the worm starts. Instead of a JavaScript loader, three packages now ship a compiled Node.js add-on that looks like a harmless helper and a hidden file called .napi_cache that looks like a leftover build cache. When the add-on runs, it decodes that file into the real payload. SafeDep warns that detection rules looking only for the earlier install trigger will miss these builds.

The payloads were too big for GitHub to search

JFrog’s first search with GitHub’s code search found the rigging in 26 repositories. It found configuration files that hook into common developer tools: .claude/settings.json for Claude, .gemini/settings.json for Gemini, two Cursor files and a VS Code tasks file. The JavaScript files those hooks pointed to seemed to be empty.

They were not. The payload wrappers were 12.9 to 13.7 MB each, and JFrog says GitHub code search did not index files that large, while GitHub’s contents API could not return them. Walking each repository’s file tree directly showed that every reachable victim repository was armed, and checking the owners’ other repositories raised the total to 42. The wrappers all decoded to the same hidden payload, designed to publish further malicious npm releases through GitHub Actions using stolen npm tokens.

JFrog also found forged commit dates that made the activity appear to stretch over months, and says the campaign had armed real repositories belonging to established developers, students and a legitimate organisation by 28 September. It does not name them.

In the same group of hijacked accounts, JFrog found workflow files linked to an earlier campaign that Socket reported in July, which abused GitHub Actions to attack internet-facing cPanel servers through CVE-2026-41940. JFrog is careful about what that shows: an operational link, “but not one proven continuous execution chain” from every npm infection to the cPanel exploit.

AI coding tools have become an execution path

The detail developers should note is the list of hooks. The operator did not rely only on npm install scripts. It planted settings for Claude, Gemini, Cursor and VS Code, so that the routine act of opening a workspace with one of those tools becomes a chance to run code. As AI coding assistants gain permission to run commands and connect to tools, their configuration files are turning into an attack surface in their own right, and they are easy to overlook in code review because they look like personal preferences rather than code.

The search gap matters as much. Defenders and researchers lean on GitHub code search to size an outbreak. In this case it reported part of the picture and suggested the payload files were empty. JFrog’s advice is to list repository trees directly rather than trust search results or the contents API. That echoes other recent supply chain cases, from the Gheist campaign that used stolen GitHub tokens to the backdoored OVHcloud CLI releases and the malicious LiteLLM release on PyPI, where stolen tokens and trusted publishing paths did the damage.

Clean-up order matters because of the wiper

The wiper changes the usual incident-response playbook. JFrog says anyone who installed a full-worm version should treat the machine as compromised, but should remove the worm’s persistence first, before revoking the stolen GitHub token, because revoking the token is what triggers the deletion of the home directory. It then recommends rotating GitHub, npm, cloud, SSH and AI-provider credentials, and auditing every repository reachable by the affected account for the hook files listed above.

The scale is still small: 42 repositories, not thousands, and SafeDep had found no downstream victims when it first wrote. But the campaign shows a worm that is being tested in public, changed when it is spotted, and planted where today’s search tools cannot see it.