Poisoned dependencies: what 232,930 malicious-package reports say about open-source supply chain risk

Of the 232,930 records, 141,131 (60.6%) describe spam: packages mass-published to farm rewards from the tea.xyz token scheme rather than to attack the people who install them. Almost all of it is on npm, and 140,728 of those records (99.7%) were filed in November 2025, when the campaign was flagged in bulk. A chart of "malicious packages per year" is mostly a chart of that one event.

The remaining 89,865 records (38.6%) describe harmful packages; a further 1,934 describe dependency-confusion probes and other reconnaissance, which we report separately. Harmful records rose from 8,757 in 2023 to 51,710 in 2025, and reached 17,468 in 2026 by 12 November.

npm accounts for 92.7% of all records and 82.3% of harmful ones. PyPI follows with 10,747 harmful records, then RubyGems (4,307) and NuGet (782). RubyGems shows the sharpest recent change: 3,372 harmful records in 2026, against 128 in 2025. The other four ecosystems together have 45.

Of the 89,865 harmful records, 53,071 (59.1%) say only that a package is malicious, often with a stock sentence that any computer running it should be considered compromised. That gap limits what defenders can learn from the data: a blocklist entry with no behaviour cannot tell a team which secrets to rotate.

Among the 36,794 records that do describe behaviour, theft dominates. Credential and data theft, such as stealing tokens, environment variables, browser data and SSH keys, accounts for 74.3%, and cryptocurrency theft for a further 7.2%: 81.5% in all. Contact with known malicious domains (9.0%), compromised legitimate packages (5.9%) and malware delivery or remote access (3.6%) make up the rest.

The emphasis on theft matters for response. Code of this kind typically runs when a package is installed or first imported on a developer laptop or build server, which is where tokens and cloud credentials live. Removing the package afterwards does not undo what it has already sent away.

2,155 records concern legitimate packages that attackers took over, typically by phishing a maintainer or stealing a publishing token, and then used to push a malicious version to everyone who depended on them. They are few compared with the total, but each can reach far more systems than a new package with an invented name.

They arrive in bursts. The records cluster in September 2025 (230), when widely used packages including ansi-regex, ansi-styles and DuckDB’s were compromised, the DuckDB case through a phishing attack on a maintainer, according to the records; November 2025 (793), described in the records as the "Sha1-Hulud: The Second Coming" worm; March 2026 (69, "CanisterWorm"); May 2026 (533, mostly "Mini Shai-Hulud"); and August 2026 (454, "Shai-Hulud: here we go again"). Several of these campaigns spread by themselves, using tokens stolen from one maintainer to publish to that maintainer’s other packages.

Defences based on suspicious names cannot catch these, because the name is the trusted one. What helps is limiting what any install can do, pinning versions so that a new release is not pulled in automatically, and protecting publishing accounts so that the next maintainer does not become the next source.

Of 300 harmful npm records from 2025 and 2026, drawn at random, npm had replaced 253 (84.3%) with its security placeholder, 28 (9.3%) had been unpublished, 12 (4.0%) were not found and 7 (2.3%) were still available. For the 238 removed packages with recorded timestamps, the median time from first publication to removal was 35 days. Only 15.5% were removed within 24 hours, and 52.1% stayed available for more than 30 days. Most (79.4%) had a single version, so the clock starts with the malicious release itself.

Public feeds lag further. In 71.0% of these cases npm removed the package before the OSV record was published. A blocklist built on OSV therefore mostly confirms what the registry has already done; its main value is in finding past installs, not preventing new ones.

This also tests a common control: refusing packages younger than a minimum age. A seven-day minimum would only have stopped the 22.7% of harmful packages that npm removed within a week. It is worth having, but not on its own. Spam behaves differently again: 45.3% of the sampled spam packages were still available, and those that npm had removed had stayed up for a median of 547 days.

Typosquatting, publishing a package whose name is a slip of the keyboard away from a popular one, is the best-known way to get malware installed. In PyPI it is real but small. Of 11,756 harmful and reconnaissance records, 964 (8.2%) are close misspellings of a top-5,000 project, 159 (1.4%) combine a popular name with other words, and 8 (0.1%) use the exact name of a top-15,000 project, which usually means that project was itself compromised. In total, 9.6% imitate a popular project.

The most imitated names are the most widely used libraries: requests (109 imitations), beautifulsoup4 (53), colorama (44), requests-toolbelt (43) and websocket-client (40). The other 90.4% use names that do not resemble a popular project. How those packages reach their victims is mostly not recorded in the data.

Name-similarity checks are cheap and worth running, but a control that only flags look-alikes would miss nine in ten malicious packages. Knowing why each new dependency is needed, and who added it, catches more.