When One Line of Code Becomes a Global Threat: The error-ex Supply Chain Attack

With 47 million weekly downloads, error-ex isn’t a flashy framework like React or Express. It’s a tiny utility, buried deep inside dependency trees. Most developers never install it directly, but it silently powers countless applications, from startups to Fortune 500 companies.

For a brief moment, this package became a ticking time bomb.

The Discovery

It started with something that looked trivial:‍

ReferenceError: fetch is not defined

That build error led investigators to version 1.3.3 of error-ex. While the previous version (1.3.2) was a clean, single-line utility, the new release was bloated with heavily obfuscated code.

Hidden inside? A function called checkethereumw — the first red flag that this wasn’t an innocent update.

What the Malicious Code Did

The malware was a sophisticated crypto-clipper. Its goal: steal funds by manipulating wallet interactions.

Here’s how it worked:

1. Wallet Detection (checkethereumw)
   • Looked for window.ethereum (MetaMask, Phantom, etc.).
   • Triggered both active and passive attack modes.
2. Passive Address Replacement (newdlocal)
   • Monkey-patched fetch and XMLHttpRequest.
   • Intercepted all outgoing network requests.
   • Searched for crypto wallet addresses in data.
   • Replaced them with attacker-controlled addresses — carefully chosen to look similar to the original, to avoid detection.
3. Active Transaction Hijacking (runmask)
   • Hooked into wallet methods like eth_sendTransaction.
   • When users tried to send funds, the recipient address was swapped with the attacker’s hardcoded wallet (0xFc4a...).
   • The user still saw a MetaMask confirmation window, but unless they inspected the address carefully, their funds were gone.

Why This Matters

This wasn’t just a crypto attack.

Because error-ex is so widely used, the malicious code could have:

• Compromised CI/CD pipelines.
• Infiltrated production servers.
• Affected developer laptops across the globe.

The blast radius is almost impossible to measure.

Ironically, the attack was caught only because the build environment used an older Node.js version that didn’t support global fetch. If not for that, it might have gone unnoticed much longer.

How to Protect Yourself

This incident underscores the need for better dependency hygiene. Here are three critical steps every team should adopt:

1. Use npm ci in CI/CD
   Unlike npm install, npm ci strictly installs exactly what’s in your package-lock.json, preventing surprise updates.
2. Pin Transitive Dependencies with overrides
   Force known-safe versions across your project:‍

"overrides": {
 "error-ex": "1.3.2"
}

1. Audit Dependencies Regularly
   • Run npm audit often.
   • Use tools like Snyk or Dependabot.
   • Review lockfile changes with the same care as code changes.

‍

Open-source thrives on trust, but trust is not a security strategy.
A single compromised dependency can ripple across the entire software world.

The error-ex incident should serve as a wake-up call:

• Lock down your dependencies.
• Harden your CI/CD pipelines.
• Build a culture of vigilance.

Because in today’s ecosystem, even one line of malicious code can put millions at risk.

Stay safe out there.