The node.js Package Manager has Been Under Attack

North Korean attackers are flooding the NPM Registry with malicious package.

North Korean threat actors have escalated their software supply chain attacks by uploading many new malicious packages to the node package manager registry as part of the ongoing Contagious Interview campaign. The NPM registry is a collection of Node.js packages, metadata, and several API endpoints that are primarily accessed via the NPM command line tool. Thus, this malware directly targets open-source JavaScript developers with malware loaders.

The XORIndex Attacks

The attacks, which began in early 2025, have intensified month over month. In June, researchers at Socket identified 28 of the newly published NPM packages using a previously undocumented malware loader named XORIndex, while 39 others used the older HexEval Loader. These packages were downloaded tens of thousands of times so this malware made its way on to systems and may still be present in the wild.

XORIndex introduces enhanced obfuscation methods, including XOR-encoded strings and index-based obfuscation, making detection more difficult. Once installed, the loader collects host telemetry, such as the system hostname, username, IP address, OS type and geolocation and transmits this data to hardcoded command-and-control servers hosted on legitimate infrastructure platforms like Vercel.

The malware then executes JavaScript payloads received from the command-and-control systems. This triggers a second-stage downloader known as BeaverTail. This component searches for and archives sensitive information including browser extension data and cryptocurrency wallet credentials. It targets nearly 50 bitcoin wallet paths and numerous browser profiles, extracting data and exfiltrating it to hardcoded IP addresses using HTTP POST requests.

The final payload, dubbed InvisibleFerret, functions as a third-stage backdoor. After data is uploaded, BeaverTail attempts to download and execute additional malicious components from the same command-and-control server, ensuring persistent access and expanded capabilities across compromised systems.

Socket researchers documented the rapid evolution of XORIndex across three developmental stages. The initial version, postcss-preloader, offered basic remote code execution with no obfuscation or telemetry collection. A second prototype, js-log-print, introduced partial reconnaissance features, though it was flawed. The third variant, dev-filterjs, implemented string obfuscation using ASCII buffers and transmitted accurate host data, paving the way for the more advanced current version of XORIndex.

This “is” Package Compromise

The attack intensified further in late July when the popular NPM package 'is' was directly compromised via a supply chain attack. It was reported that maintainer accounts were hijacked via phishing. This was followed by unauthorized owner changes that went unnoticed for several hours, potentially compromising many developers who downloaded the new releases.

The software has over 2.8 million weekly downloads on the NPM package index. It is used extensively as a low-level utility dependency in development tools, testing libraries, build systems, and backend and CLI projects.

On July 19, 2025, the package's primary maintainer, John Harband, announced that versions 3.3.1 through 5.0.0 contained malware and were removed roughly 6 hours after threat actors submitted them to NPM.

This was the result of the same NPM supply chain attack that used the fake domain' npnjs[.]com' to snatch maintainer credentials and then publish laced versions of popular packages.

Besides the “is” package, the following packages were confirmed to be pushing malware, compromised in the same attack:

· eslint-config-prettier (8.10.1, 9.1.1, 10.1.6, 10.1.7)

· eslint-plugin-prettier (4.2.2, 4.2.3)

· synckit (0.11.9)

· @pkgr/core (0.2.8)

· napi-postinstall (0.3.1)

· got-fetch (5.1.11, 5.1.12)

Socket reports that the compromised versions of 'is' contain a cross-platform JavaScript malware loader that opens a WebSocket-based backdoor, enabling remote code execution. Once this is active, it queries Node's os module to collect the hostname, operating system, and CPU details, and captures all environment variables from process.env. After this it dynamically imports the ws library to exfiltrate this data over a WebSocket connection. Every message received over the socket is treated as executable JavaScript and this provides the threat actor with an instant, interactive remote shell to do with as they please.

The researchers also analyzed the payload in 'eslint' and the rest of the packages, finding a Windows infostealer called 'Scavanger' which targets sensitive information stored in web browsers.

The malware features evasion mechanisms such as indirect syscalls, encrypted command and control (C2) communications, but it may trigger security warnings in Chrome due to flag manipulation.

Based on the attack pattern, the threat actors may have compromised additional maintainer credentials and are preparing to experiment with stealthier payloads on new software packages.

To prevent this, maintainers should reset their passwords and rotate all tokens immediately, and developers should only use known-to-be-safe versions. This means to avoid and remove versions from 3.3.1 through 5.0.0.

A timeline of node.js attacks

• Local package patching (March 2025): A new and highly sophisticated method was discovered where attackers published malicious packages like ethers-provider2 that secretly "patched" legitimate packages installed locally on a machine. This allowed them to deliver a reverse shell and maintain persistence even if the initial malicious package was removed.

• North Korean "XORIndex" malware (April-June 2025): Researchers identified 67 malicious npm packages linked to North Korean threat actors. The packages used malware loaders like "XORIndex" and "HexEval" and were downloaded thousands of times.

• "Is" package compromise (July 2025): The popular is package, with millions of weekly downloads, was compromised after attackers successfully phished and hijacked a maintainer's account. The attackers published malicious versions that included a backdoor to collect environment variables and exfiltrate data via a WebSocket connection.

• "Scavenger" malware campaign (July 2025): This campaign used phishing to compromise the accounts of maintainers for multiple packages, including eslint-config-prettier. The malicious code dropped a DLL file, dubbed "Scavenger," which was designed to steal sensitive data like npm authentication tokens and browser information.

• AI-generated malware (August 2025): A malicious package, @kodane/patch-manager, was discovered that researchers believe was generated using AI. The package was designed to act as a Solana wallet drainer.

Key Takeaways

This attack focuses attention on supply chain attacks and key software dependencies utilized by software developers and DevOps teams. To protect from these kinds of threats, development teams need to build security in the process from the start, rather than treating security as a separate task at the end of the cycle. This way organizations can create more secure software, reduce risks, and improve overall project success. Some key takeaways for DevOps and DevSecOps teams can mitigate this, and other threats would be to implement the following best practices:

1. Secure the CI/CD pipeline

• Isolate build environments: Run CI/CD jobs in isolated, non-persistent environments to limit damage from a compromised pipeline.

• Enforce least privilege: Ensure that build agents and pipelines run with the minimum permissions necessary.

• Use two-factor authentication (2FA): Require 2FA on developer accounts and public repositories like GitHub and NPM to prevent unauthorized access.

2. Manage dependencies securely

• Regularly audit packages: Use tools like npm audit, Snyk, and Dependabot to scan for known vulnerabilities in your project's dependencies.

• Lock dependency versions: Use package-lock.json or yarn.lock to ensure all developers use the same dependency versions, preventing unexpected vulnerabilities.

• Use trusted packages: Avoid using single-line or obscure code packages that have a low usage rate.

3. Harden application code and configuration

• Sanitize and validate input: Sanitize and validate all user input to prevent injection attacks like SQL injection and cross-site scripting (XSS).

• Implement security headers: Use middleware like Helmet to set security-related HTTP headers, protecting against XSS and clickjacking.

• Disable debugging in production: Ensure the Node.js Inspector debugging interface is disabled in production, as it can be a backdoor for executing malicious code.

• Protect secrets: Never hardcode secrets (API keys, database credentials) in your code. Use environment variables or a dedicated secret management tool.

4. Maintain and monitor your applications:

• Update regularly: Always use the latest Long-Term Support (LTS) version of Node.js, which receives ongoing security patches.

• Enable comprehensive logging: Implement robust logging and monitoring to detect suspicious activity and gain insights during an incident.

• Limit exposure: Use a reverse proxy (like Nginx) or a cloud load balancer to act as a buffer between the public internet and your Node.js application.

From a security perspective it is impossible to leave out the fact that the “is” package compromise was ultimately caused by a hijacked repository maintainer account via a phishing attack. This indicates that:

• Security training was lacking or consciously lapsed.

• Proper security protections were not present (email gateway defense, firewall, XDR antivirus, etc) for these key individual computer environments.

In summary, the software development lifecycle needs to integrate security activities, testing, and overall best practices. Also, developers and repository maintainers must accept that proper security controls on their own networks and systems need to be in place to protect the very products that they are authoring and managing.

This falls right back to the fact that “security is everyone's responsibility” (including maintainers, developers and DevOps teams) and a layered security approach must be in place to protect these critical resources if they are to be relied upon.