← All posts
October 19, 2026 · DevSecOps

npm in 2026: Booby-Trapped Packages, Hijacked Trusted Publishing and How to Protect Yourself

Over 1,500 npm packages exposed to takeover through a Trusted Publishing flaw, fake dotenv packages hiding malware in an image, worms spreading from package to package: the JavaScript supply chain has never been under so much attack. Maintainers and developers, here is what to do.

Where things stand in October 2026

In just a few weeks, the npm ecosystem piled up alerts:

  • Trusted Publishing flaw (disclosed October 13): more than 1,500 packages, with over 10 million total downloads, could be published by an attacker without stealing a single credential.
  • "Darkroom" campaign: fake packages posing as dotenv hid a PowerShell command inside a JPEG image, leading to the installation of an info-stealer on Windows.
  • Self-propagating worms (Shai-Hulud style): a compromised package steals the developer's npm tokens, then publishes trojanized versions of the other packages they maintain.

The common thread: npm install runs code written by strangers, often without review, and more and more often triggered by an AI agent.

1. Understanding the Trusted Publishing flaw

Trusted Publishing replaces long-lived npm tokens with short-lived credentials issued to a specific GitHub Actions workflow. A good idea, except that npm identified the bound repository by its name only (owner/repo), without checking the permanent numeric ID GitHub assigns to every repository and account.

The attack scenario, demonstrated by Bloom Security:

  1. A maintainer renames, transfers or deletes the repository bound to their package (or renames their account).
  2. The old name becomes available again. The attacker creates a repository with that name.
  3. They add a workflow with the same file name as the configured one.
  4. npm hands them a valid publish credential: they publish a new version of the package, with a valid provenance attestation pointing to their own repository.

GitHub announced a fix on October 2: unvalidated configurations now expire 48 hours after creation. According to the researchers, the GitLab integration had the same weakness.

What maintainers should do

# List the Trusted Publishing bindings of your packages
npm trust list
  • Check that every listed repository still exists and belongs to you.
  • Delete and re-create any binding pointing to a renamed or transferred repository.
  • Remove the binding before deleting or renaming a repository.

2. Protecting yourself as a developer

Install reproducibly

# In CI and production: strictly follows the lockfile
npm ci

# Blocks preinstall/postinstall scripts, the main vector for npm malware
npm ci --ignore-scripts

To make it the default for a project:

# .npmrc
ignore-scripts=true
save-exact=true

If a package really needs an install script (native compilation, for example), run it explicitly after review with npm rebuild <package>.

Check provenance and signatures

# Verifies registry signatures and provenance attestations
npm audit signatures

In the Trusted Publishing case, the attestation was valid but pointed to the attacker's repository. So don't settle for "provenance present": check that the repository it names is the project's official repository.

Let new versions age

Most trojanized versions are detected and pulled within hours or days. Not installing a version published 10 minutes ago greatly reduces the risk. Example renovate.json:

{
  "minimumReleaseAge": "3 days",
  "packageRules": [
    { "matchUpdateTypes": ["major"], "dependencyDashboardApproval": true }
  ]
}

Watch out for typosquatting

Fake packages bet on a typo or a believable name (such as dotenv-runtime, removed from the registry on October 7). Before adding a dependency:

  • Check the download count, creation date and source repository.
  • Copy the name from the official documentation rather than typing it.
  • Be wary of recent packages that ship binary files or images for no reason.

3. Protecting your tokens and your CI

npm worms spread by stealing tokens found on the developer's machine or in CI.

  • Enable 2FA on your npm account, in "authorization and publishing" mode.
  • Prefer Trusted Publishing (correctly configured) over long-lived automation tokens.
  • Leave no npm token in ~/.npmrc on a machine where you install packages every day.
  • In CI, give the GITHUB_TOKEN the minimum (contents: read) and isolate the publish step in a separate job.

4. AI agents amplify the risk

Coding agents install dependencies themselves, often without anyone reviewing them. According to the researchers, a typical developer machine sees around 350 package installs a month this way.

  • Require human approval before any npm install started by an agent.
  • Apply ignore-scripts=true in environments where agents work.
  • Run agents in a container or devcontainer, without publish tokens.

Checklist

  • [ ] npm ci in CI, never npm install
  • [ ] ignore-scripts=true by default, scripts allowed case by case
  • [ ] npm audit signatures in the pipeline, provenance checked against the official repository
  • [ ] Minimum delay before adopting a new version (Renovate / Dependabot)
  • [ ] Maintainers: npm trust list reviewed, orphaned bindings removed
  • [ ] npm 2FA enabled, no long-lived tokens on development machines
  • [ ] Installs made by AI agents reviewed and isolated

Sources: Help Net Security — npm Trusted Publishing flaw · CSO Online — 1,500+ packages exposed