Popular npm Package With 150K Weekly Downloads Compromised in Mini Shai-Hulud Supply-Chain Attack

A JavaScript development package has been caught in a supply-chain compromise that can run malicious code when installed. The incident affects a tool with about 150,000 weekly downloads, risking developer and automated build systems.

Attackers published ten tainted releases on August 28 in two bursts. They covered every maintained version line, and a routine dependency update could become an entry point for credential theft.

The malicious code runs during installation through build configuration abuse and, in some releases, a pre-install command.

Socket.dev said in a report shared with Cyber Security News (CSN) that it unlocks a hidden program that searches for credentials in files, processes, cloud services, and continuous-integration environments.

Socket.dev analysts identified the activity as an ongoing Mini Shai-Hulud compromise. It can reuse stolen access and alter build environments, potentially turning an installation into a wider supply-chain problem.

Popular npm Package With 150K Weekly Downloads

The package generates code that connects applications with APIs. Malicious releases carried valid npm provenance records, meaning proof that an approved workflow built a package did not reveal malicious code in the release.

The compromised versions were signed through GitHub Actions trusted publishing. Researchers found that a release workflow could be triggered by a comment on a pull request, then checked out code from that pull request’s fork and published it with the trusted identity.

The workflow did not verify that the commenter was a trusted repository contributor. Provenance can show which automated workflow produced an artifact, but cannot confirm that it built safe source code.

The teams should review safeguards around publishing jobs, especially workflows that react to external comments while holding permissions to publish packages or obtain identity tokens.

The installation route echoes the technique described in this earlier binding.gyp supply-chain incident, where build metadata activated code outside the lifecycle scripts that many checks focus on.

Here, the implanted program was hidden inside a scrambled JavaScript file and launched through the native-build path.

Credential Theft and Containment Steps

Once active, the payload searches project files, process memory, cloud metadata services, and CI variables for access tokens and other secrets.

It checks whether stolen credentials work, collects the results in encrypted form, and stores them in attacker-created public GitHub repositories. This can expose code-hosting, package-registry, cloud, and developer-tool access at once.

The malware also alters GitHub Actions workflows, monitors tokens on macOS and Linux, and adds background commands to AI coding-assistant settings.

It can use reachable SSH hosts for propagation and poison packages under writable registry scopes. Its behavior resembles the credential-led spread covered in the earlier Shai-Hulud supply-chain attack, though overlap alone does not prove the same operators are responsible.

The organizations should treat an installation of an affected release as a possible host compromise. Teams should isolate the machine or runner first, preserve evidence, neutralize persistence, and only then revoke or test exposed tokens, because the monitor may react when a stored GitHub token returns an error.

Affected environments should be rebuilt from a known-clean image where practical. After containment, administrators should rotate accessible package, GitHub, cloud, CI, and developer-tool credentials, inspect lockfiles and software bills of materials for direct and indirect use, clear caches, and reinstall from a clean lockfile pinned to a known-good release.

Security teams should review repository creation, workflow changes, deployment activity, suspicious dependency-update commits, and unexpected artifacts.

Related reporting on compromised GitHub Actions secrets shows why CI runners deserve the same incident-response urgency as employee endpoints. Maintainers should require trusted-contributor checks before a comment-triggered workflow can publish code.

This case reinforces the lesson from the Keyv npm package compromise: dependency trust cannot rest on a registry signature or provenance record alone.

Reviewing release triggers, locking dependencies, and limiting token privileges can reduce the blast radius when a trusted publishing path is abused.

Indicators of compromise (IoCs):-

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Prevent incidents due to slow investigations. Power your Tier 1 with threat intelligence from 15K SOCs: Integrate TI Lookup in your SOC