Attackers breached 42 third-party GitHub repositories by hiding malicious code inside files so large that GitHub's search and API tools couldn't scan them, according to a security research firm JFrog, which disclosed the findings on Monday. The compromised repositories contained execution hooks for AI coding assistants and integrated development environments, along with polymorphic wrappers as large as 13.7MB that all decoded to the same hidden payload. The campaign also featured a compiled native addon that carries no payload itself but instead decrypts a file named .napi_cache at runtime to reveal the actual malicious code.
JFrog's investigation uncovered account hijacks, forged commit timelines, short-lived publishing branches, and exposed npm credentials across the victimized repositories. The firm's scanners first detected shai-hulud packages in the npm ecosystem on October 21, while SafeDep's October 22 analysis documented the npm side of the activity and decoded a package called event-bus-lite-testmetest. SafeDep initially believed the packages in the campaign, dubbed testmetest, were merely a test by the threat actor, but this week discovered that existing repositories had been compromised with malicious content. The malicious testmetest releases used a binding.gyp command expansion to execute code during installation, even though the packages didn't declare a conventional install script, and the loader applied a per-build Caesar transformation to decrypt an AES-128-GCM stage. The full npm payload collected credentials, poisoned repositories and continuous integration configuration, and spread through package registries.
The researchers wrote that the planted files include execution hooks for Claude, Gemini, Cursor, and Visual Studio Code, meaning that opening a project in a supported tool can trigger the payload. "The attacker read the documentation for your detection tooling and padded the file past its limits," said Aman Mahapatra, chief strategy officer for Tribeca Softech, noting that the 13MB wrappers exceed what GitHub code search indexes and what the contents API returns. JFrog recommended that security leaders treat installation of a full-worm version as a host compromise and that users should revoke and rotate all GitHub, GitLab, npm, PyPI, RubyGems, cloud, SSH, Vault, Kubernetes, and AI-provider credentials.
The particulars of this attack reveal how supply chain threats have evolved beyond traditional install-time defenses, according to the report. For years, the supply chain threat model assumed malicious code ran when something was installed or executed, but this campaign plants hooks so the payload runs when a developer simply opens the repository in their tool. The native addon also refuses to run inside continuous integration systems, containers, small virtual machines, or under a debugger, and on Windows it stands down if Wireshark or Process Monitor is running, meaning scanners see a placeholder but a developer's laptop gets the real thing. Frank Dickson, principal analyst at Dickson Research, noted that a developer's laptop holds GitHub tokens, npm tokens, cloud keys, and AI provider credentials, and attackers have found a new way to ask for them.
JFrog suggested that companies enumerate repository trees directly rather than relying on GitHub code search or the contents API because of the wrapper size issue, and that IT teams should audit all repositories accessible to affected identities for specific execution hooks including .github/init.js, .claude/settings.json, .gemini/settings.json, and .cursor/mcp.json. The firm also recommended deleting unauthorized branches, disabling malicious workflows, removing fake CodeQL artifacts, and hunting GitHub Actions logs for specific indicators like /tmp/.svc and unusually broad scans from hosted or self-hosted runners. These hooks are features, not flaws, according to analysts, but the root cause remains stolen credentials rather than the AI tools themselves—though a feature that runs code when a folder opens deserves the same scrutiny as a build script. Organizations that rely on folder-level trust in their development workflows may need to rethink access controls at the moment code enters a local environment, not just when it ships to production. The shift from install triggers to open triggers suggests that perimeter defenses designed for yesterday's attack surface won't catch tomorrow's compromise.