The Great NPM Heist – What Happened and How InvisiRisk Protects You

In early September 2025 attackers orchestrated a large-scale supply chain compromise on the NPM registry. They phished several popular package maintainers to gain publishing rights, then pushed malicious updates to over 18 widely used JavaScript libraries (including chalk, debug, ansi-regex, strip-ansi, wrap-ansi, color-convert, etc.).

These packages alone have billions of weekly downloads. The injected code was a sophisticated cryptocurrency stealer: it wrapped browser APIs (like window.ethereum) to detect crypto wallets and replace legitimate wallet addresses in Web3 transactions with attacker-controlled ones. In effect, any user loading a compromised package risked having their crypto payments silently redirected to the attackers. This represents one of the largest NPM supply-chain breaches ever, enabled simply by hijacking maintainer accounts.

The attack leveraged the inherent trust in open-source dependencies and maintainers. Developers routinely install packages from NPM without verifying every update, assuming libraries like chalk or debug are benign. By compromising the maintainer accounts, the attackers injected code that evaded static scanners (it was heavily obfuscated) and immediately took advantage of automated build pipelines. In short, the exploit targeted the software supply chain’s weakest link: trust and automation. This incident underscores the maxim: “Trust is a vulnerability.” Even fundamental dev tools and libraries can be weaponized if not properly checked.

How the Attack Worked

1. Malicious Update Published: The attacker gained access to a maintainer’s NPM account and published a new version of a popular package. To the continuous integration (CI) system, this looked like a routine dependency update.

2. Hidden Payload in Code: The new version contained obfuscated JavaScript. At runtime (e.g. when an application or build step loads the module), the code would silently scan for cryptocurrency wallet addresses and intercept Web3 calls.

3. Transaction hijacking: If a wallet was detected (e.g. window.ethereum present), the code replaced the recipient address in any outgoing transaction with one controlled by the attacker. It also monitored network requests (overwriting fetch/XHR) to hijack DeFi transactions.

4. Wide Distribution: Since the packages were transitively required by many projects, the infected code quickly spread. Automated build systems pulled in these versions without alarm, inadvertently spreading the trojan into new applications.

Safeguard your Build with InvisiRisk

To secure your supply chain from poisonings like this, InvisiRisk offers a Build Application Firewall (BAF), essentially a security layer that wraps around your CI/CD pipeline. Instead of only scanning source code, the BAF monitors and enforces policies on the build process itself. But protection goes beyond just known vulnerabilities. We provide a holistic package quality assessment through our proprietary IR Score.

• This score is the result of a multi-faceted risk analysis, evaluating packages based on critical factors such as:

• The presence of known critical vulnerabilities.

• The quality and completeness of package descriptions.

• The consistency and health of its version maintenance, among many others.

• Its age, since brand-new packages are often the source of attacks, as seen in recent NPM supply chain incidents.

• The OpenSSF Scorecard, an industry initiative that assesses the overall security hygiene of open-source projects through checks like dependency updates, CI/CD security, and code review practices.

By combining proprietary analysis with industry-recognized benchmarks like the OpenSSF Scorecard, the IR Score provides a more credible and comprehensive view of package risk.

The IR Score abstracts away the complexity of manual vetting. Instead of your team needing to weigh every potential risk factor, the BAF provides a single, actionable intelligence metric that helps you manage risk effectively. Security by its nature is about balancing threat prevention with productivity, and the IR Score gives you a practical way to monitor and control that balance. For example, using a simple yet powerful Rego policy, you can configure your BAF to flag or block packages with an IR Score above a chosen threshold, say 8. This ensures that higher-risk packages such as newly created ones with little history are surfaced early, allowing you to make informed decisions before they enter your build.

InvisiRisk not only protects against new threats before they reach your build, but also keeps watch on the dependencies you’ve already installed. If a vulnerability is later discovered in an existing package, you’ll receive timely notifications, ensuring your build stays secure long after deployment.

Key advantages include:

• Proactive Policy Enforcement: During the build, InvisiRisk BAF checks the tools and dependencies involved. For example, it can automatically block known vulnerable or malicious packages by version. If a malicious NPM release is detected (because it matches a policy rule), the build is stopped before the code even runs. This turns the pipeline into a proactive filter.

• Trusted Source Validation: The BAF ensures your builds only pull code from approved sources. It can enforce that packages come from a trusted registry or repository. In practice, this means an attacker’s attempt to slip in a package from an unknown mirror or third-party CDN (or even an unapproved Git hosting) would be automatically blocked. Even if the malicious code lives in NPM, policies can restrict unexpected channels or new upstreams.

• Runtime Build Protection: As InvisiRisk explains, “security must be embedded directly into the build process to block threats in real time”. The BAF effectively acts as a firewall during builds since it watches for suspicious actions (like pushing code back to the repository, or leaking secrets) and halts them. For instance, one default rule blocks any unauthorized git push initiated by a build script, preventing hidden scripts from silently modifying your main branch.

• Secrets and Traffic Monitoring: InvisiRisk’s BAF even inspects build-time network traffic to catch potential leaks. It scans the payloads of outbound requests for secrets (API keys, tokens, etc.). In a compromised build, if the malware tried to exfiltrate sensitive data during a package download or initialization, the BAF would intercept and block that activity. This goes beyond simple header checks; it looks at entire request bodies for anything secret.

• Safe Failure and Alerts: Crucially, if a policy is violated (e.g. a build tries to install a blocked package or use a disallowed tool version), the BAF “intervenes and halts the build before the malicious command can be fully executed”. The build fails safely, and an alert is sent to the team detailing the issue (which package or tool triggered the block and which policy caught it).

Figure: InvisiRisk BAF Blocking Malicious Activities.

Unleash the Power of Custom Policies: Limitless Possibilities

We understand that every organization has unique security requirements. That’s why InvisiRisk BAF doesn’t just stop at providing the IR Score, it also gives you the freedom to define your own guardrails through custom policies written in Rego.

If you can describe a rule, you can likely implement it as a policy within our platform. For example, some organizations may want to block packages that were published less than X days ago to reduce exposure to untested or tampered versions. With a few lines of Rego, you can enforce this directly in your build pipeline.

This flexibility empowers your security team to create highly specific controls tailored to your risk profile and workflows. Whether it’s limiting package age, restricting certain registries, or enforcing naming conventions, custom policies extend protection far beyond default settings.

And it’s not just theoretical; we built a proof of concept where our BAF successfully blocked a brand-new NPM package version solely based on its release date.

Figure: Custom Rego Policy Blocking Recently Released Package.

By combining the IR Score with the limitless flexibility of custom policies, InvisiRisk BAF ensures that security is not only comprehensive but also customizable to your needs.

In summary, InvisiRisk’s BAF turns your CI/CD pipeline into a proactive, real-time security guard. Rather than finding an issue after deployment, it blocks malicious changes as they enter the build. This “firewall for your build pipeline” ensures not just your code but the very tools used to build it are safe. For example, if a future NPM malware attempt tried to push a tainted version of chalk, BAF’s default rules (plus customizable Rego-based policies) could immediately prevent that version from ever being built or deployed.

Key Takeaways:

• Modern CI/CD pipelines can propagate malware at scale in minutes. Don’t wait for a reactive scan to catch a poisoned dependency.

• Build-time firewalls like InvisiRisk BAF enforce safety checks on tools and packages. They block known risky packages and untrusted sources by default.

By integrating InvisiRisk Build Application Firewall into your development workflow, you add a real-time shield around your supply chain. It’s a practical way to ensure that even if attackers try to slip malware into NPM or Git, your build process will catch it and shut it down before any damage is done.