Safeguard
Supply Chain•

npm incident history, from left-pad in 2016 to worms in 2025

A dated list of npm security incidents from one reference article, from left-pad to self-spreading worms, and what each says about registry risk.

Safeguard Security Team
3 min read

npm has had a long run of notable incidents, from left-pad in March 2016 to self-spreading worms in 2025. They fall into a few types: removal, maintainer protest, malicious dependencies and credential theft. Each type needs a different control, which is why one blanket rule rarely works.

The list

As summarised in the Wikipedia article on npm. Details here are only what that article states:

  • March 2016, left-pad. A package was unpublished in a naming dispute, breaking projects including Babel and Webpack. npm changed its unpublish policy.
  • November 2018, event-stream. flatmap-stream was added to event-stream 3.3.6, with an encrypted payload that stole bitcoins from certain applications.
  • May 2021, pac-resolver. A package with over 3 million weekly downloads had a remote code execution vulnerability, fixed in version 5 and later.
  • January 2022, colors and faker. The maintainer of colors published code that printed garbage text in an infinite loop, and replaced faker with a protest README.
  • March 2022, node-ipc. A maintainer added peacenotwar as a dependency, which overwrote files on machines with Belarusian or Russian IP addresses, in protest of the invasion of Ukraine.
  • May 2023, bignum. Several packages were exploited to steal credentials and information.
  • September 2025. Up to 18 popular packages were compromised after a phishing attack on maintainers. The malware redirected cryptocurrency transactions in the browser.
  • September 2025, Shai-Hulud. A self-replicating worm stole GitHub developer credentials to spread, and as of 16 September had affected more than 187 packages.

The article also lists later events in 2025 and 2026. This post leaves those out because only that one page was used and recent claims should be checked against primary reports.

Four types of risk

  1. Removal. A package disappears. Lockfiles and mirrors help.
  2. Maintainer action. A trusted author changes the code on purpose. Pinning and review help.
  3. Malicious addition. A new dependency appears in a release. Diffing dependency changes helps.
  4. Credential theft. An attacker uses stolen publish rights. Strong maintainer authentication and monitoring help.

What to do

Pin versions, review changes in dependency updates, and delay adoption of brand new releases by a short window for non-urgent upgrades. Keep a way to see which packages you use and where.

Reading the list critically

A list from one reference article is a starting point, not a full record. It may omit incidents and compress details. For anything you plan to cite in a report, go to the maintainer statements or the registry advisory. Also note that these incidents differ a great deal. A protest change by a maintainer is a governance problem, a phishing attack on maintainers is an authentication problem, and a removal is an availability problem. Putting them into one bucket hides the right fix for each.

Quick check

What was the event-stream payload designed to do?

Steal bitcoins from certain applications, per the source cited below.

Which control helps most against a package being removed?

Lockfiles together with a mirror or cache of dependencies.

Safeguard's dependency scanning and policies can flag risky package changes, and there is a free scan at gold.safeguard.sh/scan.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.