NewsCSO OnlineSMEPublic sector

    Attackers compromised 42 GitHub repositories by using files too large to be searched

    Share
    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 settings, Cursor MCP configuration and rules, and VS Code folder-open tasks, so the payload runs when a developer simply opens the repository in their tool. .claude/settings.json is the new autorun.inf .” “Attackers have moved the trigger from running code to opening a folder, built malware that hides from sandboxes by design, and turned the industry’s last fix into the next target,” Mahapatra said. “Supply chain defense built around install-time scanning is now guarding the wrong moment.” He said he was especially worried about the file size tactic that the attackers leveraged. “The 13MB wrappers add a cruder trick. They exceed what GitHub code search indexes and what the contents API returns, which is why early analysis found the hooks and concluded the payload files were empty,” Mahapatra said. “The attacker read the documentation for your detection tooling and padded the file past its limits.” Frank Dickson , principal analyst at Dickson Research, said he was also impressed with the attacker’s use of a native addon. “It carries no payload of its own and refuses to run inside CI systems, containers, small virtual machines, or under a debugger,” he said. “On Windows, it also stands down if Wireshark or Process Monitor is running. The scanners see a placeholder but the developer’s laptop gets the real thing.” Dickson said the AI risk element is there, but it’s a secondary exposure that is only an issue once the attackers steal active credentials. Still, it is worse due to agentic efforts. “The planted files are execution hooks for Claude, Gemini, Cursor, and VS Code. Opening a project in a supported tool can run the payload. A routine developer action becomes the detonator. A developer’s laptop holds the keys to the kingdom if you will: GitHub tokens, npm tokens, cloud keys, and AI provider credentials. Attackers have found a new way to ask for them,” Dickson said. “To be fair, these hooks are features, not flaws. The root cause here is stolen credentials, not the AI tools. Still, a feature that runs code when a folder opens deserves the same scrutiny as a build script.” This article originally appeared on InfoWorld .

    Linked advisories

    Affected vendors and products

    More on GitHub

    Other advisories

    Other news entries

    Source: https://www.csoonline.com/article/4241496/attackers-compromised-42-github-repositories-by-using-files-too-large-to-be-searched-2.html

    ID