The Shai-Hulud worm is a supply chain malware campaign targeting the npm package registry. Initially discovered in September 2025, it involves trojanized npm packages that steal sensitive developer credentials including API keys, cloud credentials, and npm/GitHub tokens. These stolen tokens are then used to exfiltrate data to attacker-controlled GitHub repositories and to propagate the worm by injecting malicious code into other popular npm packages associated with the compromised developer accounts. The newly identified strain, embedded in the "@vietmoney/react-big-calendar" package uploaded by "hoquocdat," was updated in December 2025 with obfuscation changes, renamed payload files ("bun_installer.js" and "environment_source.js"), and removal of a destructive dead man switch that previously wiped systems if no tokens were found. The worm also improved error handling and adjusted the order of data collection. Despite limited spread observed so far, the worm’s ability to weaponize npm tokens to infect up to 100 other packages creates a high risk of rapid supply chain compromise. Concurrently, a similar supply chain attack was detected on Maven Central involving a typosquatted malicious Java package masquerading as a legitimate Jackson JSON library extension. This package delivers a multi-stage attack chain that downloads and executes Cobalt Strike beacons, enabling post-exploitation control. The Maven attack exploits namespace prefix similarity to deceive developers and evade repository detection. Both campaigns highlight critical blind spots in package repository security, emphasizing the need for enhanced verification of package namespaces and vigilant monitoring of developer tokens and package integrity.

For European organizations, the Shai-Hulud worm represents a significant threat to software supply chain integrity and developer credential security. Organizations relying on npm packages for development risk exposure of sensitive API keys, cloud credentials, and repository tokens, which could lead to unauthorized access to cloud environments, code repositories, and deployment pipelines. The worm’s self-propagation capability could rapidly compromise multiple widely used packages, amplifying the attack surface and potentially affecting thousands of downstream projects and applications. This can result in data breaches, service disruptions, and loss of trust in software supply chains. The related Maven Central attack introduces additional risk by delivering Cobalt Strike beacons, which enable attackers to establish persistent command-and-control channels for further exploitation, lateral movement, and data exfiltration. European enterprises with active software development, DevOps, and cloud operations are particularly vulnerable. The stealthy nature of these attacks and the use of legitimate developer tools and tokens complicate detection and response efforts, increasing the potential for prolonged undetected compromise.

1. Enforce strict vetting and verification of all third-party packages before inclusion in projects, focusing on package provenance, publisher reputation, and namespace legitimacy. 2. Implement automated scanning of dependencies for known malicious patterns, obfuscation, and unusual updates, leveraging threat intelligence feeds and behavioral analysis. 3. Rotate and tightly control API keys, cloud credentials, and repository tokens; use least privilege principles and monitor token usage for anomalies. 4. Employ multi-factor authentication and token expiration policies to reduce the risk of token abuse. 5. Monitor package repositories for typosquatting and namespace impersonation attempts; repository maintainers should flag suspicious packages for manual review. 6. Use software composition analysis (SCA) tools integrated into CI/CD pipelines to detect and block malicious or unauthorized package versions. 7. Educate developers on supply chain risks and encourage reporting of suspicious package behavior or unexpected dependency changes. 8. For Maven users, verify package namespaces carefully and avoid dependencies from untrusted or unknown sources. 9. Establish incident response plans specifically addressing supply chain compromises, including rapid revocation of compromised tokens and package version rollbacks. 10. Collaborate with package repository maintainers and security communities to share indicators of compromise and improve detection capabilities.