Software Supply Chain Wars: npm Strikes Back (again)!

In June, a tiny JavaScript package called error-ex was quietly compromised. error-ex is a one-line utility buried deep in the dependency trees of thousands of projects Despite its simplicity, the package is downloaded automatically via dependency managers like npm over 47 million times per week, making it a silent cornerstone of the modern web. For a brief window, it became a vector for malware capable of infiltrating CI/CD pipelines, production servers, and developer machines across the globe.

This compromise was subtle. A developer noticed a cryptic build failure: ReferenceError: fetch is not defined. Digging deeper, they discovered that although their project specified version 1.3.2 of error-ex, a newer version, 1.3.3, had been silently installed. This version contained heavily obfuscated code, including a clearly malicious function name: check ethereum w. The malware appeared designed to steal cryptocurrency, and the build only failed because the Node.js version lacked a global fetch function. In newer environments, the attack would have gone unnoticed.

Figure 1. Obfuscated code in v1.3.3 of error-ex package

Soon after, researchers uncovered that 18 other popular npm packages had been similarly compromised. Altogether, these packages are downloaded over 2 billion times per week.

The malware injected into these packages was sophisticated and browser-based. It intercepted crypto and web3 activity, manipulated wallet interactions, and silently redirected payments to attacker-controlled accounts. It operated across multiple layers of the development stack, altering website content, hijacking API calls, and rewriting transaction data. This made it nearly impossible for users to detect the malicious behavior.

How did this happen? One maintainer of the error-ex package was phished. A fake email, sent from a domain registered just days earlier, created a false sense of urgency and tricked the developer into handing over access. That single lapse opened the door to a global-scale supply chain attack.

Figure 2. Phishing email received by error-ex developer

While the impact of this incident was limited, the chain of compromise further reinforces that the open-source ecosystem, built on trust and good intentions, is dangerously fragile. A single compromised maintainer or package can ripple across the entire software landscape, affecting everything from hobby projects to critical government systems.

So what can defenders and IT managers do? While the scale of software supply chain attacks can seem overwhelming, we can begin to consistently take action to diminish this every growing threat to our businesses:

• Stronger vetting of maintainers and package updates.
• Automated dependency monitoring and version pinning.
• Security audits for critical packages.
• Education and awareness to prevent phishing and social engineering.
• Verification of SBOMs (Software Bill of Materials) to ensure transparency in what’s being shipped.
• Legal and compliance reviews of third-party software usage, especially in regulated industries.
• Adherence to supply chain security guidance from trusted sources like NIST, CISA, and OWASP.

This isn’t just a problem for your dev team to worry about. This affects our bottom line. If your organization relies on open-source software (and it almost certainly does), now is the time to ask: Are we doing enough to secure our supply chain?