How Attackers Gain Control of Popular NPM Packages

How Attackers Gain Control of Popular NPM Packages

Nobody breaks into npm. They walk in through the front door, usually because someone handed them the key.

A phishing email pretending to be a two-factor authentication reset, a fake npm support ticket, a cloned login page — send it to enough maintainers of high-traffic packages and one of them will click. That's exactly what happened in September 2025, when the npm account of a well-known JavaScript developer was compromised through a phishing message, giving attackers publish access to `chalk`, `debug`, `ansi-styles`, `strip-ansi`, and several other packages that together sit in the dependency tree of a large share of the JavaScript ecosystem. `chalk` alone gets pulled hundreds of millions of times a week. You almost certainly have it three or four layers deep in something you run right now.

Second route: slow social engineering against a package's trust structure, not its login page. The `event-stream` incident in 2018 is the textbook case. An attacker calling themselves "right9ctrl" spent months submitting helpful pull requests to the (at the time under-maintained) `event-stream` package, earned co-maintainer status, then quietly added a dependency called `flatmap-stream` that carried malicious code targeting the Copay bitcoin wallet. Npm's own postmortem is worth reading in full — it's a rare instance of a registry operator being candid about how the trust model failed. ([blog.npmjs.org](https://blog.npmjs.org/post/180565383195/details-about-the-event-stream-incident.html))

Third route: the maintainer does it themselves. In January 2022, the maintainer of `colors.js` and `faker.js` deliberately pushed updates that broke thousands of downstream projects — an infinite loop printing garbled text in one case, deleted functionality in the other — as a protest over unpaid open-source labor. A few months later, in March 2022, the maintainer of `node-ipc` shipped versions 10.1.1 and 10.1.2 that wiped files on machines with Russian or Belarusian IP addresses, in protest of the invasion of Ukraine. ([theregister.com](https://www.theregister.com/2022/03/18/protestware_javascript_node_ipc/)) Different motive, same lesson: you're trusting a person, not a license file.

Fourth, less dramatic but increasingly common: dependency confusion and typosquatting. Publish a public package with the same name as a company's internal private package, give it a higher version number, and npm's default resolution will happily pull the public — malicious — one into a corporate build. Security researcher Alex Birsan demonstrated this against dozens of major companies in 2021, legitimately, for bug bounty. Attackers have been running the same trick illegitimately ever since.

Red Flags: What a Compromised Dependency Actually Does

The payload usually falls into one of four buckets, and knowing which one you're dealing with tells you how fast you need to move.

• Credential and token harvesting. The self-propagating worm that spread through npm in September 2025, tracked by researchers under the name "Shai-Hulud," scanned infected machines for AWS keys, GCP credentials, GitHub personal access tokens, and npm publish tokens, then used any it found to republish itself into other packages the stolen credentials could access. That's the part that should worry CI/CD teams most: it didn't just steal, it spread using what it stole.
• Cryptocurrency theft. The 2025 `chalk`/`debug` compromise deployed a browser-based "clipper" — code that watches for cryptocurrency wallet addresses in transaction data and silently swaps in an attacker-controlled address. `event-stream` did the same thing against a specific wallet application seven years earlier. The mechanism barely changed; only the target did.
• Sabotage without theft. `colors.js` and `node-ipc` prove the payload doesn't need to steal anything to hurt you. A build that suddenly fails, an application that suddenly deletes files — that's a production incident even if no data ever left the building.
• Reconnaissance and dormancy. Some payloads do nothing visible for weeks. They phone home, fingerprint the environment, and wait for a more valuable target to show up in the logs before acting. This is the category that makes "it hasn't caused a problem" a meaningless statement of safety.

Practically, the things to watch for in a diff or a changelog:

• A `postinstall` or `preinstall` script added to a package that never had one.
• A minor version bump with an unusually large, obfuscated, or minified code change.
• A new co-maintainer added to the npm registry entry shortly before a suspicious release.
• Network calls in the code to domains that have nothing to do with the package's stated purpose.
• A sudden jump in the package's requested install-time permissions or scope.

The Attack Timeline: From Compromise to Detection

Every one of these incidents follows roughly the same shape, and the shape is the useful part — it tells you where your defenses actually need to sit.

1. **Compromise.** Credentials stolen, trust earned, or a maintainer's own decision. This can take an afternoon (phishing) or several months (the `event-stream` pattern). 2. **Publish.** The malicious version goes live on the public registry, indistinguishable at a glance from a routine patch release. 3. **Silent propagation.** Every CI pipeline, developer laptop, and production build running an unpinned version range (`^4.1.0` rather than a locked `4.1.0`) pulls the new version automatically on the next install. This is the window that does the damage, and it's measured in downloads, not time. `event-stream`'s malicious dependency sat live for roughly two and a half months before anyone noticed. The 2025 `chalk`/`debug` incident, by contrast, was reportedly caught within hours of publication — but "hours" against a package with hundreds of millions of weekly downloads still means an enormous number of installs happened before the fix. 4. **Detection.** Usually a researcher, an automated scanner, or a developer noticing something odd — a build that behaves strangely, a bundle size that jumped, a network call that shouldn't exist. 5. **Takedown and advisory.** The registry pulls or deprecates the version, and an advisory gets published, often through GitHub's advisory database or the maintainer's own postmortem. 6. **Remediation, everywhere else, on someone else's schedule.** This is the part that takes months, because it depends on every downstream project actually noticing the advisory and updating.

The gap between step 3 and step 6 is where the actual financial and reputational damage accumulates. Detection is a headline. Remediation is a slog.

Real-World Impact on Odoo Implementations Using Vulnerable Dependencies

Odoo's core Python codebase doesn't lean heavily on npm — but pretending your Odoo stack is npm-free is wrong, and the places where it isn't are exactly the places people forget to check.

Odoo's own documentation for installing from source instructs administrators to run `npm install -g rtlcss` as part of getting a working instance, for right-to-left language CSS support. ([odoo.com](https://www.odoo.com/documentation/18.0/administration/on_premise/source.html)) That's an npm package, installed globally, often with elevated privileges, on the same server that holds your production database. It is one package among the ecosystem's roughly two million, and it has exactly the same theoretical exposure as `chalk` or `debug` — it's just smaller and less frequently targeted, which is a reason for lower probability, not zero risk.

The bigger exposure sits with custom development, not core Odoo. We've run `npm ls` against a client's custom point-of-sale kiosk build — a relatively modest OWL (Odoo Web Library) front-end extension — and watched it return several hundred transitive dependencies for what was, functionally, a few thousand lines of first-party code. That ratio is normal in the JavaScript world and abnormal by the standards of a typical Odoo Python module, which is why it catches Odoo-focused teams off guard. Add a payment gateway connector, a WhatsApp integration, or an EDI middleware service — all commonly bolted onto Odoo implementations and frequently built as standalone Node.js services — and you've added another full dependency tree, another `package-lock.json`, and another surface that nobody on the accounting-software side of the project is watching.

The practical failure mode isn't Odoo getting hacked directly. It's a CI pipeline building a custom Odoo module pulling a compromised npm package during the build step, exfiltrating the pipeline's GitHub token or deployment credentials, and using those credentials to reach the actual production server. The compromise happened in JavaScript tooling. The damage lands in Python and PostgreSQL.

Detection Tools and Monitoring Strategies That Work

None of these are exotic technology. What's usually missing is the discipline to keep them switched on after the initial setup sprint.

• Lockfiles, committed and enforced. `package-lock.json` or `yarn.lock`, checked into version control, with CI configured to fail if the lockfile and `package.json` disagree. This alone closes the "silent propagation" window from the timeline above — an unpinned version range is how a malicious patch release reaches you automatically.
• `npm audit` as a CI gate, not a manual chore. Run it on every build, not once a quarter, using the severity thresholds npm's own documentation covers in detail. It also generates a steady stream of false positives — vulnerabilities in transitive dependencies that never execute in your actual code path — and if nobody owns triaging that noise, teams tend to start ignoring the tool's output within a few months, which puts you back where you started. ([docs.npmjs.com](https://docs.npmjs.com/auditing-package-dependencies-for-security-vulnerabilities))
• GitHub Dependabot alerts, enabled on every repository that has a `package.json`. That includes the internal tooling and integration microservices nobody thinks of as "the Odoo project" — the WhatsApp connector repo, the EDI middleware, the deploy scripts sitting in their own quiet corner of the org. ([docs.github.com](https://docs.github.com/en/code-security/dependabot/dependabot-alerts/about-dependabot-alerts))
• npm provenance statements for anything your own team publishes, which cryptographically ties a published package back to the specific CI build that produced it — useful for you, and increasingly expected of the packages you consume. ([docs.npmjs.com](https://docs.npmjs.com/generating-provenance-statements))
• `--ignore-scripts` on install, in CI and production build environments, wherever the build doesn't specifically require a native compilation step. Most supply-chain payloads execute through `postinstall` hooks, so turning them off by default removes the easiest delivery mechanism. The tradeoff is real: some packages rely on `postinstall` to compile or download platform-specific binaries, and blocking scripts wholesale will break those installs outright, so you need a deliberate exception list rather than a blanket flag.
• A private registry proxy (Verdaccio, Artifactory, or similar) sitting between your builds and the public npm registry, so a compromised package has to clear an internal allowlist before it reaches a build server. It's real infrastructure, not a checkbox — someone has to maintain the allowlist, approve new packages on request, and keep the proxy itself patched, or it just becomes a slow, unmaintained middleman sitting in front of every build.
• OpenSSF Scorecard or similar automated scoring against your direct dependencies, to flag packages with single maintainers, no 2FA enforcement, or stale publishing history — the exact conditions that preceded most of the incidents above.

Step-by-Step Recovery When Your Supply Chain Is Affected

If an advisory names a package in your dependency tree, the sequence matters more than the speed of any individual step. Rotate credentials before you've actually confirmed which systems were exposed, for instance, and you'll burn the incident window chasing accounts that were never at risk while the real exposure sits untouched.

1. **Confirm exposure precisely.** Run `npm ls <package-name>` across every repository, not just the one that prompted the alert. Compromised packages are often transitive, buried three or four dependencies deep, and easy to miss with a surface-level check. 2. **Pin to a known-good version immediately**, don't just "update" — updating blind can pull you into a different bad version if the compromise is still active or the maintainer account is still in attacker hands. 3. **Rotate every credential the affected build pipeline had access to.** Deployment keys, cloud provider tokens, database passwords used in CI, third-party API keys. Assume anything reachable from that pipeline's environment variables was read. 4. **Audit CI and build logs for the exposure window**, looking specifically for outbound network calls to unfamiliar domains, unexpected package publishes under your organization's npm scope, and unrecognized SSH keys or deploy hooks added during the affected period. 5. **Rebuild from a clean environment.** Don't trust an incremental build on a machine that ran the compromised package. Wipe `node_modules`, clear build caches, rebuild from the pinned, known-good lockfile. 6. **Check production, not just the build pipeline.** If the compromised package's payload targeted browsers (a clipper injected into a web bundle, for instance), any customer-facing environment served from that build needs the same rebuild-and-redeploy treatment, and the incident needs disclosure if customer data or funds were plausibly exposed. 7. **Add the monitoring you didn't have.** Every incident review ends the same way — someone asking why Dependabot wasn't turned on, or why the lockfile wasn't enforced. Do that work now, while the incident is still fresh enough to justify the budget for it.