The testmetest worm: 13 MB payloads in 42 GitHub repos

The npm campaign called testmetest, which looked like a simple trial run with no victims, had in fact already armed 42 real GitHub repositories belonging to 11 owners. This was documented by JFrog Security Research in a report on October 26, covered by The Register and CSO Online. The detail that makes the campaign hard to find: the payload files weigh between 12.9 and 13.7 MB, beyond the limits of GitHub code search and the contents API. heise Security also reported the story, but its text was not available for this analysis.

A few days ago we covered Gheist, which uses stolen GitHub tokens to pull secrets out of Actions logs. testmetest is a different campaign: a worm that spreads through npm, steals credentials and hides inside victims’ repositories.

From “test” to real victims

According to The Register, the company SafeDep was the first to spot the campaign, with 18 npm packages published by the same operator between October 19 and 25. In its October 22 analysis, which decoded event-bus-lite-testmetest@0.0.1, SafeDep had found no compromised third-party packages: all activity seemed to come from the operator’s own test accounts. SafeDep linked the payload to the Miasma family, while noting uncertainty about its lineage. The Register reports that the code is shared with June’s Miasma Phantom Gyp worm and adds the Mini Shai-Hulud wiper, which deletes the victim’s home directory when the victim revokes the stolen GitHub token.

JFrog, whose systems had flagged Shai-Hulud-type packages on npm on October 21, instead found account hijacks dating back to July, forged commit timelines, short-lived publishing branches and exposed npm credentials.

How the chain works

npm package installation. According to the report quoted by CSO Online, the malicious releases use a command expansion in binding.gyp to run index.js during installation, without declaring an install script. The loader applies a per-build Caesar transformation to a character-code array, decrypts an AES-128-GCM stage and locates or downloads Bun 1.2.18; the payload is piped to bun run - or written to a temporary .b-* directory that is removed after execution. The full payload collects credentials, modifies repositories and CI configurations, and spreads through package registries.

Armed repositories. In hijacked repositories the campaign leaves harmless placeholders or real payloads: execution hooks for AI assistants and development environments (a Claude Code SessionStart hook, Gemini settings, Cursor MCP configuration and rules, VS Code folder-open tasks) and polymorphic wrappers of 12.9 to 13.7 MB that all decode to the same hidden payload. Opening the project in one of these tools is enough to run it. The armed ci.js files contain publishers designed to run in GitHub Actions and use npm tokens or trusted publishing to release new malicious versions: the loop closes.

Size as camouflage. The wrappers exceed what GitHub code search indexes and what the contents API returns: this is why, according to an analyst quoted by CSO Online, early analyses found the hooks but concluded the payload files were empty.

Native add-on and evasion. A compiled add-on carries no payload of its own: it decrypts a .napi_cache file at runtime. Before starting, the loader looks for CI runners, containers, sandboxes and debuggers and, if it finds them, exits silently. A second build skips the encrypted file and downloads a loader from a repository on the operator’s GitHub account, CementBeetleSteeple, which hosted 17 campaign repositories; according to JFrog, an attacker repository also acts as an active sink for encrypted data.

Link to cPanel. JFrog ties the same account to a “shellpanel” scanner, previously described by Socket in a campaign that used GitHub Actions in compromised repositories to exploit CVE-2026-41940, an authentication bypass in cPanel and WHM (in CISA’s KEV catalog since April, with fixed versions available), and steal server credentials. JFrog states that it did not confirm any downstream cPanel compromises.

In our reading, the relevant MITRE ATT&CK techniques are T1195.002 (Compromise Software Supply Chain), T1078 (Valid Accounts), T1027 (Obfuscated Files or Information), T1497 (Virtualization/Sandbox Evasion), T1552.001 (Credentials In Files) and T1485 (Data Destruction) for the wiper.

Impact for European and Italian companies

The risk concerns anyone who develops with npm packages or works on third-party GitHub repositories: a developer’s laptop holds GitHub and npm tokens, cloud keys and AI provider keys. With AI assistant hooks, the dangerous moment is no longer just installation, but also simply opening a project. For NIS2 entities, software supply chain security is a required measure, and the use of stolen credentials on production systems should be assessed as a potentially reportable incident.

What to do now

JFrog’s recommendations as reported by CSO Online, unless stated otherwise:

1. Treat as compromised any machine where a full version of the worm was installed.
2. Before revoking tokens (our advice): the wiper described by The Register triggers when the GitHub token is revoked. Isolate the machine and secure the home directory data, then proceed.
3. Revoke and rotate GitHub, GitLab, npm, PyPI, RubyGems, cloud, SSH, Vault, Kubernetes and AI provider credentials.
4. Check every repository reachable by the affected identities: .github/init.js, .claude/settings.json, .gemini/settings.json, .cursor/mcp.json, .cursor/rules/setup.mdc, .vscode/tasks.json, unexpected hooks in composer.json or Makefile, commits with skip-checks:true. Enumerate the file tree directly: do not rely on code search or the contents API.
5. Clean up: delete unauthorized chore/ci-* and deps/upd-* branches, disable malicious workflows, remove fake CodeQL artifacts named scan-output.
6. Block hxxp[:]//43[.]228[.]157[.]68:80 and related infrastructure.
7. Hunt GitHub Actions logs and runners for /tmp/.svc, ipscan, references to CVE-2026-41940, /api/dl/<arch> requests and unusually broad scans; on machines, for .napi_cache files.
8. Update cPanel and WHM to the versions fixed for CVE-2026-41940, if you use them.

How ARXDOME helps

ARX Sentry’s agent collects logs, events, process inventory and file integrity monitoring in the chosen folders, including on developer workstations and self-hosted runners. With ARX Trace our analysts can launch collections and searches across multiple machines to look for the indicators listed above, and ARX Shield can isolate a suspicious machine from the network before tokens are revoked.

Last updated: 29 October 2026