A security research firm reported Monday that it had identified breaches of 42 third-party GitHub repositories in which attackers had deployed payload blobs large enough “to evade the GitHub search and API paths normally used to find this kind of compromise.”
The report from JFrog Security Research said the victimized repositories contained execution hooks for AI coding assistants and IDEs, along with polymorphic wrappers as large as 13.7MB that “all decoded to the same hidden CI-publisher payload. The campaign’s attacker-owned repository also operates as an active encrypted data sink, receiving snapshot envelopes, and the attack leveraged a new camouflage: a compiled native addon that contains no payload of its own, and instead decrypts a file named .napi_cache at runtime to reveal the real one.”
JFrog said that the investigation also uncovered account hijacks, forged commit timelines, short-lived publishing branches and exposed npm credentials. Shellpanel artifacts in the same hijacked owner cluster link this GitHub victim infrastructure to previously reported GitHub Actions exploitation of internet-facing cPanel systems.
“During October 21 our scanners alerted us about shai-hulud packages found in the npm ecosystem,” JFrog wrote. “SafeDep’s October 22 analysis first documented the npm/package side of this activity and decoded event-bus-lite-testmetest@0.0.1. SafeDep described the payload as Miasma-family while explicitly noting uncertainty about its lineage.”
SafeDep had originally thought that the packages in the campaign it had discovered, dubbed testmetest, were merely a test by the threat actor, but this week discovered the compromises of existing repos with malicious content.
The JFrog post also focused on the npm chain implications.
“The npm chain provides the link into the broader operation. Malicious testmetest releases used a binding.gyp command expansion to execute index.js during installation, even though the packages did not declare a conventional install script,” the post said. “The loader applied a per-build Caesar transformation to a character-code array, decrypted an AES-128-GCM stage and located or downloaded Bun 1.2.18. Depending on the build, the decrypted payload was piped to bun run - or written to a temporary .b-*directory and removed after execution. The full npm payload collected credentials, poisoned repositories and CI configuration, and propagated through package registries.”
Those attacker-controlled repositories served as sources of cover projects for matching npm packages, JFrog said.
“Malicious releases delivered the npm worm, which stole GitHub and npm credentials that could provide access to third-party repositories. Within hijacked repositories, the campaign left smoke-test placeholders or armed payloads,” the researchers wrote. “Decoding the armed ci.js files exposed publishers designed to run through GitHub Actions and use npm tokens or trusted publishing to produce further malicious testmetest releases, feeding package delivery back into repository compromise.”
Defensive recommendations
JFrog’s post recommended a variety of defensive tactics for detection and mitigation of these attacks, including that CISOs “should treat installation of a full-worm version as a host compromise.” It also suggested that users should revoke and rotate all GitHub, GitLab, npm, PyPI, RubyGems, cloud, SSH, Vault, Kubernetes and AI-provider credentials, as well as auditing “all repositories accessible to affected identities for .github/init.js, .claude/settings.json, .gemini/settings.json, .cursor/mcp.json, .cursor/rules/setup.mdc, .vscode/tasks.json, unexpected composer.json or Makefile execution hooks, and skip-checks:true commits.”
JFrog also suggested that companies enumerate repository trees directly and that IT should not rely on GitHub code search or the contents API, because of the wrapper size issue.
“Delete unauthorized chore/ci-* and deps/upd-* branches, disable malicious workflows and remove fake CodeQL artifacts named scan-output. Block hxxp[:]//43[.]228[.]157[.]68:80, and related malicious infrastructure at network controls” and “hunt GitHub Actions logs and runners for /tmp/.svc, ipscan, CVE-2026-41940, architecture-specific /api/dl/ requests and unusually broad scans from hosted or self-hosted runners,” JFrog suggested. And. Of course, look for .napi.cache.
High priority target
The popularity of GitHub repositories is likely going to continue to make them a high-priority target for attackers.
Aman Mahapatra, chief strategy officer for New York City-based technology consulting firm Tribeca Softech, said the particulars of this attack will likely predict the path of new AI-focused attacks for the immediate future.
“For a decade, the supply chain threat model assumed malicious code ran when you installed or executed something,” he said. “This campaign plants a Claude Code SessionStart hook, Gemini
[…]
Content was trimmed to protect the source. Please visit the original article for the full text.
Read the original article:
Attackers compromised 42 GitHub repositories by using files too large to be searched