kief.dev
· 6 min read

The 10 npm Packages Most Likely to Get Compromised Next

Kief Studio
The 10 npm Packages Most Likely to Get Compromised Next

I'll write the full blog post now based on the research brief and voice guidelines.

The 10 npm Packages Most Likely to Get Compromised Next

Your node_modules folder has 1,200 packages in it. You wrote maybe 15 of them. The rest were written by strangers, maintained by volunteers, and installed because some package you actually wanted pulled them in three levels deep.

One of those strangers got phished in September 2025. That single compromised account gave attackers publish access to debug, chalk, and 16 other packages. 2.6 billion weekly downloads, weaponized overnight. CISA issued an alert. The attack vector was a fake 2FA reset email from npmjs.help.

Then in March 2026, North Korean state actors hit axios. 70 million weekly downloads. Present in roughly 80% of cloud environments. Microsoft, Google Cloud, and CISA all published advisories within 72 hours. RAT execution was observed in 3% of affected orgs before anyone even knew it happened.

So which packages are next?

The Risk Profile That Keeps Repeating

Every major npm supply chain attack in the last two years follows the same pattern. Not zero-days. Not clever exploits. Social engineering and neglect.

The event-stream attack from 2018 set the template: find a burned-out maintainer, offer to "help," get publish access, ship malware. Eight years later, it still works. Tidelift surveyed 400+ open source maintainers in 2024 and found 60% have quit or considered quitting due to burnout.

Here's what makes a package a target:

  • Single maintainer (or a small group where one person has full publish rights)
  • High download count (millions per week, deep in transitive dependency trees)
  • No OIDC trusted publishing (still using long-lived npm tokens)
  • Minimal recent activity (maintainer hasn't pushed in months)
  • Runs postinstall scripts (or could be modified to add one)

That last point matters more than people think. Every major npm supply chain attack in 2025-2026 used postinstall or preinstall hooks as the execution vector. A string formatting library doesn't need network access or shell execution. npm gives it that power anyway.

The Packages That Fit

I'm not going to pretend I have a crystal ball. But I can grep the npm registry for packages matching that risk profile. Here are the ones that should keep you up at night.

minimist -- 45M+ weekly downloads. Argument parsing. It's already been compromised once (prototype pollution, 2020). The maintenance pattern is sparse. It sits in the dependency tree of thousands of CLI tools, most of which pull it transitively through packages like mkdirp or optimist.

glob -- 30M+ weekly downloads. File matching. Critical infrastructure for build tools. isaacs maintains it well, but it's a single point of failure for half the Node.js ecosystem.

semver -- 50M+ weekly downloads. Version parsing. Owned by npm/GitHub, which helps, but "owned by a large org" didn't save axios. The attack surface is the maintainer accounts, not the org chart.

qs -- 40M+ weekly downloads. Query string parsing. Used by Express. Small maintainer surface. If you run a Node.js web server, you almost certainly have this in your tree.

color-convert, supports-color, ansi-styles -- the chalk dependency family. These were already caught in the September 2025 blast radius. They're patched now. But the same structural risks that made them vulnerable haven't changed. Small maintainer groups, massive download counts, deep transitive reach.

ms -- 25M+ weekly downloads. Converts time strings to milliseconds. 73 lines of code. One maintainer. Used by debug, which is used by everything.

mime-types and mime-db -- 40M+ weekly downloads combined. MIME type lookups. Pulled in by Express, request, and dozens of HTTP libraries. Quiet maintenance history.

ini -- 25M+ weekly downloads. INI file parsing. Already had a prototype pollution CVE. Sparse commit history. Deep in the npm CLI's own dependency tree.

These aren't predictions. They're observations about structural risk. The next compromise will hit a package with this exact profile -- high downloads, few maintainers, deep transitive reach, and an auth setup that relies on a single human not clicking a phishing link.

The Attack Vectors That Actually Work

Forget theoretical vulnerabilities. Here's what's actually compromising packages right now.

Credential Theft at Scale

The Shai-Hulud worm, active from September through November 2025, was the first self-replicating malware in npm history. It stole npm and GitHub tokens from compromised machines, then automatically published poisoned versions of every package those tokens could access. 500+ packages in days. When credential theft failed, the v2.0 variant switched to destructive sabotage -- it overwrote and deleted the victim's entire home directory.

The second wave hit packages maintained by Zapier, PostHog, Postman, and ENS Domains. Not because those companies were targeted. Because their maintainers had tokens on machines that got popped.

Volume Flooding

The IndonesianFoods campaign published a new malicious package every 7 seconds in Q4 2025. Over 100,000 packages total. It effectively doubled the total npm malware count overnight. The npm registry's defenses couldn't keep up with that velocity.

454,648 malicious npm packages were published in 2025 alone. 99.8% of all open-source malware in Q4 2025 came from npm.

AI Hallucination Squatting

This one is new. 28% of LLM-assisted dependency upgrades hallucinate non-existent package versions. Attackers are registering those names preemptively. Your AI coding assistant suggests npm install left-pad-utils@2.0.0, that package doesn't exist, but an attacker registered it last week. You install malware because Copilot made it up.

What You Should Actually Do

npm audit isn't going to save you. Dan Abramov called it "broken by design" and he's right. It flags a ReDoS in a dev-only build tool with the same severity as a RAT in a production dependency. 65% of teams bypass or delay fixes due to alert fatigue (Aikido Security, 2026). The teams that survived September 2025 weren't running npm audit. They had version pinning and lockfile verification.

Here's what actually works:

Pin exact versions

Stop using caret ranges. The Axios RAT spread because teams had "axios": "^1.14.0" in their package.json and npm happily pulled the compromised 1.14.1.

{
  "dependencies": {
    "axios": "1.14.0",
    "express": "4.21.2",
    "debug": "4.4.0"
  }
}

Set this globally so you never forget:

npm config set save-exact true

Kill postinstall scripts by default

npm config set ignore-scripts true

Then whitelist the packages that genuinely need build steps:

{
  "scripts": {
    "postinstall": "echo 'scripts disabled by default'"
  },
  "overrides": {}
}

In your .npmrc:

ignore-scripts=true

When you need to allow scripts for a specific package (like esbuild or sharp that ship platform binaries):

npm rebuild esbuild
npm rebuild sharp

Verify your lockfile in CI

# This fails if package-lock.json doesn't match package.json exactly
npm ci

# Never run 'npm install' in CI -- it can modify the lockfile

Scan for malicious packages, not just CVEs

npm audit checks the npm advisory database for known CVEs. It doesn't catch supply chain attacks, typosquats, or compromised maintainer accounts. Tools like Socket.dev and Snyk analyze package behavior -- network calls, filesystem access, obfuscated code -- and flag suspicious patterns before they show up in any advisory database.

Or scan your lockfiles locally:

# Scan a project's lockfile for known malicious packages and CVEs
vekt scan ./package-lock.json

# Check multiple lockfiles across a monorepo
vekt scan --recursive .

Vekt checks against OSV.dev for both CVE and MAL-* advisories (the malicious package database). It covers npm plus 11 other ecosystems, so your Python and Rust dependencies get the same treatment.

Audit your dependency tree

You probably don't know what's in your transitive dependencies. Fix that:

# How deep is your dependency tree?
npm ls --all | wc -l

# Find who pulled in a specific package
npm ls minimist

# Check for duplicate versions
npm ls --all | grep "minimist@" | sort -u

If npm ls minimist shows it coming in through 12 different paths, that's 12 opportunities for one of those intermediate packages to get compromised and drag minimist along with it.

The Uncomfortable Truth

The problem isn't any specific package. It's the npm execution model itself.

When you run npm install, you're granting arbitrary code execution to every package in your dependency tree. A library that parses query strings gets the same permissions as your application code. It can open network connections, read your filesystem, execute shell commands, and exfiltrate your credentials.

npm is slowly tightening auth -- deprecating legacy tokens, pushing OIDC trusted publishing. But adoption is slow. And some maintainers argue that moving auth to CI pipelines just shifts the attack surface to GitHub Actions, which has its own typosquatting problem (@acitons/artifact got 47,000 downloads before anyone noticed the typo).

The next big npm compromise isn't a question of if. It's a question of which package in that list above gets hit first. Pin your versions. Kill postinstall scripts. Scan your lockfiles. And stop trusting npm audit to be your security strategy.

Your node_modules folder is a trust exercise with 1,200 strangers. Act accordingly.

meta_title: "10 npm Packages Most Likely to Get Compromised Next"
meta_description: "Structural risk analysis of high-download, single-maintainer npm packages and the three things your team should do before the next supply chain attack."
tags: ["npm", "supply-chain-security", "javascript", "open-source-security", "vekt"]
← Back to blog