JFrog Security Research has found 42 GitHub repositories that attackers rigged with execution hooks and hidden malicious code. The researchers link them to the npm worm campaign "testmetest". How many machines ran the code and what data was stolen is still unknown.
The 42 repositories belong to 11 legitimate owners. The attackers slipped in the malicious code, which JFrog says resembles variants of Shai-Hulud, through hijacked accounts or contributor permissions. The security firm SafeDep had already described the npm side of the campaign on October 22, but at the time found neither compromised third-party packages nor victims.
AI assistants and IDEs as the trigger
In the repositories, the attackers placed project configuration files for developer tools. If you launched the project with Claude Code, Gemini or Cursor, for example, or opened it as a VS Code workspace with the right settings, those files could run the hidden file .github/init.js. You did not have to start a script on purpose.
JFrog lists 15 npm packages with at least one version flagged as malicious:
- data-pipeline-testmetest, event-bus-lite-testmetest, event-emitter-testmetest
- log-rotate-testmetest, log-sink-testmetest, net-codec-testmetest
- npm-publish-testmetest, pixel-map-testmetest, retry-utils-testmetest
- test-brotli-testmetest, test-brotli2-testmetest, path-stream-utils-testmetest
- @iobandamwer/cache-helper, @iobandamwer/native-helper, @testsecuiitytestme/cache-helper
After GitHub and npm credentials
Some of the packages contain a worm that mainly collects GitHub and npm credentials and can spread on its own. In .github/init.js, JFrog also found obfuscated publisher code. Among other things, it looks for GitHub tokens and uses any available npm publishing rights to push tampered package versions, for example through GitHub Actions.
Some of the hijacked repositories also contained Shellpanel workflows that attack cPanel systems through the critical flaw CVE-2026-41940. The researchers do not see evidence of a complete chain from npm infection to exploitation of that flaw, though.
Invisible to code search
Depending on the variant, the payload .github/init.js was 12.9 to 13.7 MB in size. GitHub code search does not index files that large, and the usual Contents API did not return the content either. Only when JFrog listed the repository trees through the Git Trees API and fetched the file directly as a Git blob did the code show up.
A newer variant hides even better. In @iobandamwer/cache-helper, @iobandamwer/native-helper and path-stream-utils-testmetest, the malicious code is not readable JavaScript but sits encrypted in a file called .napi_cache. A compiled add-on shipped with the package decrypts it at runtime. Before that, it checks whether it is running in an analysis environment and bails out if so. According to a SafeDep update from October 27, the add-on in @testsecuiitytestme/cache-helper launches the worm as soon as the package is imported. At that point, --ignore-scripts no longer protects you.
The attackers run their own repositories for their infrastructure, 17 of them under the GitHub account CementBeetleSteeple. One of them, stable-scripts-9965, serves as a drop point. On October 25 it held 27 files following the pattern data/snap-*.json with what is likely encrypted data. What they contain and how many victims there are remains unclear, since JFrog only analyzed the metadata.
What you should do now
JFrog recommends examining affected systems and, if in doubt, rebuilding them from trusted sources. Check repository configurations and workflows, and revoke any credentials that may have leaked. Mind the order, though: according to SafeDep, the worm installs a wiper that deletes the home directory as soon as the stolen GitHub token is revoked. Back up important data first.