Summarizer

Postinstall script dangers

Focus on how the attack leveraged postinstall hooks, with recommendations to use pnpm/bun which prompt for script approval, or set ignore-scripts=true globally

← Back to Axios compromised on NPM – Malicious versions drop remote access trojan

The recent compromise of Axios via a hidden postinstall script has sparked urgent calls for developers to abandon default install behaviors in favor of the manual approval workflows found in pnpm and bun. While global configurations like `ignore-scripts=true` and "minimum release age" filters provide a vital defensive layer, some commenters warn that constant prompts can lead to security fatigue or fail to stop malware that executes during runtime. This tension has prompted a push toward reducing attack surfaces by opting for native features like Node’s fetch and sandboxing development environments in VMs or containers. Ultimately, the community is shifting toward a stricter "zero-trust" model, emphasizing that without rigorous vetting of transitive dependencies, the convenience of modern package management remains a significant liability.

33 comments tagged with this topic

View on HN · Topics
I think the AI tooling is, if not completely solving sandboxing, at least making the default much better by asking you every time they want to do something and providing files to auto-approve certain actions. Package managers should do the same thing
View on HN · Topics
> at least making the default much better by asking you every time they want to do something Really? I thought 'asking you every time they want to do something' was called 'security fatigue' and generally considered to be a bad thing. Yes you can concatenate files in the current project, Claude.
View on HN · Topics
I can't even imagine the scale of the impact with Axios being compromised, nearly every other project uses it for some reason instead of fetch (I never understood why). Also from the report: > Neither malicious version contains a single line of malicious code inside axios itself. Instead, both inject a fake dependency, [email protected] , a package that is never imported anywhere in the axios source, whose only purpose is to run a postinstall script that deploys a cross-platform remote access trojan (RAT) Good news for pnpm/bun users who have to manually approve postinstall scripts.
View on HN · Topics
Does pnpm block postinstall on transitive deps too or just top-level? We have it configured at work but I've never actually tested whether it catches scripts from packages that get pulled in as sub-dependencies.
View on HN · Topics
It prompts for transitive dependencies, too. I have never had workerd as a direct dependency of any project of mine but I get prompted to approve its postinstall script whenever I install cloudflare's wrangler package (since workerd needs to download the appropriate Workers runtime for your platform).
View on HN · Topics
From what I can tell, it blocks it everywhere.
View on HN · Topics
That's solid, really helps lock down the supply chain attack surface. Do you ever end up having to whitelist anything that legitimately needs to run on install?
View on HN · Topics
After using pnpm for years (at least 5, don't remember exactly), I've only ever had to whitelist one library that uses a postinstall script to download a native executable for your system. And even this is not necessary, it's just poorly designed. For example, esbuild and typescript 7 split binaries for different systems and architectures into separate packages, and rely on your package manager to pull the correct one.
View on HN · Topics
> Good news for pnpm/bun users who have to manually approve postinstall scripts. Would they not have approved it for earlier versions? But also wouldn't the chance of addition automatic approval be high (for such a widely used project)?
View on HN · Topics
The prompt would be to approve the new malicious package (plain-crypto-js)'s scripts, too, which could tip users off that something was fishy. If they were used to approving one for axios and the attackers had just overwrote axios's own instead of making a new package, it would probably catch people out.
View on HN · Topics
Assuming axios didn't have a postinstall script before, it wouldn't have been approved for a previous version. If you ignore it, you ignore it, but postinstall scripts are relatively rare in npm deps, so it would seem a bit out of place when the warning pops up.
View on HN · Topics
Can't speak for other devs but I like to read postinstall scripts or at least put them through an LLM if they're too hard to grok. It's also a little context dependent, for example if I was using Axios and I see a prompt to run the plain-crypto-js postinstall script, alarm bells would instantly ring, which would at least make me look up the changelog to see why this is happening. In most cases I don't even let them run unless something breaks/doesn't work as expected.
View on HN · Topics
PSA: npm/bun/pnpm/uv now all support setting a minimum release age for packages. I also have `ignore-scripts=true` in my ~/.npmrc. Based on the analysis, that alone would have mitigated the vulnerability. bun and pnpm do not execute lifecycle scripts by default. Here's how to set global configs to set min release age to 7 days: ~/.config/uv/uv.toml exclude-newer = "7 days" ~/.npmrc min-release-age=7 # days ignore-scripts=true ~/Library/Preferences/pnpm/rc minimum-release-age=10080 # minutes ~/.bunfig.toml [install] minimumReleaseAge = 604800 # seconds (Side note, it's wild that npm, bun, and pnpm have all decided to use different time units for this configuration.) If you're developing with LLM agents, you should also update your AGENTS.md/CLAUDE.md file with some guidance on how to handle failures stemming from this config as they will cause the agent to unproductively spin its wheels.
View on HN · Topics
Where in the pnpm documentation does it say that it ignores scripts by default? From https://pnpm.io/cli/install#--ignore-scripts : > Default: *false*
View on HN · Topics
Weird. The config also appears to default to `false` https://pnpm.io/settings#ignorescripts
View on HN · Topics
This page describes the behavior, "disables the automatic execution of postinstall scripts in dependencies": https://pnpm.io/supply-chain-security While this explicitly calls out "postinstall", I'm pretty sure it affects other such lifecycle scripts like preinstall in dependencies. The --ignore-scripts option will ignore lifecycle scripts in the project itself, not just dependencies. And it will ignore scripts that you have previously allowed (using the "allowBuilds" feature).
View on HN · Topics
Was this an drive-by/auto-install attack?
View on HN · Topics
This only works for post-install script attacks. When the package is compromised, just running require somewhere in your code will be enough, and that runs with node/java/python and no bwrap.
View on HN · Topics
AFAIK maven doesn’t support post install logic like npm does. You have to explicitly optin with build plugins. It doesn’t let any arbitrary dependency run code on your machine.
View on HN · Topics
some post processors have chains to execution (ex: lombok)
View on HN · Topics
You explicitly opt in by using a compiler plugin. Merely having it as a dependency, like in npm, doesn’t mean it can run code at build time.
View on HN · Topics
Rejecting any packages newer than X days is one nice control, but ultimately it'd be way better to maintain an allowlist of which packages are allowed to run scripts. Unfortunately npm is friggen awful at this... You can use --ignore-scripts=true to disable all scripts, but inevitably, some packages will absolutely need to run scripts. There's no way to allowlist specific scripts to run, while blocking all others. There are third-party npm packages that you can install, like @lavamoat/allow-scripts, but to use these you need to use an entirely different command like `npm setup` instead of the `npm install` everyone is familiar with. This is just awful in so many ways, and it'd be so easy for npm to fix.
View on HN · Topics
The problem is that package managers are a distraction. You have to sandbox everything or else it doesn't work. These attacks use post-install hooks for convenience but nothing would have stopped them patching axios itself and just waiting for devs to run the app on their local workstation. So you end up needing to develop in a fully sandboxed environment.
View on HN · Topics
Yeah the whole rush on "post-run hooks bad" isn't really adding all that much to security. Like congratulations, your dev was compromised whole 10 minutes later after he ran code.
View on HN · Topics
PNPM makes you approve postinstall scripts instead of running them by default, which helps a lot. Whenever I see a prompt to run a postinstall script, unless I know the package normally has one & what it does, I go look it up before approving it. (Of course I could still get bitten if one of the packages I trust has its postinstall script replaced.)
View on HN · Topics
JS package managers (pnpm, bun) now will ignore postinstall scripts by default. Except for npm, it still runs them for legacy reasons. You should probably set your default to not run those scripts. They are mostly unnecessary. ~/.npmrc : ignore-scripts=true 83M weekly downloads!
View on HN · Topics
Essential steps to minimise your exposure to NPM supply chain attacks: — Run Yarn in zero-installs mode (or equivalent for your package manager). Every new or changed dependency gets checked in. — Disable post-install scripts. If you don’t, at least make sure your package manager prompts for scripts during install, in which case you stop and look at what it’s going to run. — If third-party code runs in development, including post-install scripts, try your best to make sure it happens in a VM/container. — Vet every package you add. Popularity is a plus, recent commit time is a minus: if you have this but not that, keep your eyes peeled. Skim through the code on NPM (they will probably never stop labelling it as “beta”), commit history and changelog. — Vet its dependency tree. Dependencies is a vector for attack on you and your users, and any new developer in the tree is another person you’re trusting to not be malicious and to take all of the above measures, too.
View on HN · Topics
The postinstall script vector is getting all the attention, but IMO the scarier part is how the attacker chain works: compromise one package's credentials, use that access to pivot to the next target. Trivy -> LiteLLM -> now potentially axios. Each compromised package becomes a credential harvester for the next round.\n\nThe min-release-age configs (now in npm, pnpm, bun, uv) are a good start, but they only work as herd immunity — you need enough early adopters installing fresh releases to trigger detection before the 7-day window expires for everyone else. It's basically a bet that security researchers will catch it faster than your cooldown period.\n\nFor Node specifically: if you're still using axios for new projects, it's worth asking why. Native fetch has been stable in Node since v21. One less dependency in your tree is one less attack surface.
View on HN · Topics
With all the recent supply chain attacks, I'm starting to think it's only a matter of time before all of us are victims. I think this is a sign to manually check all package diffs or postinstall scripts.
View on HN · Topics
Absolutely. If you ever did a npm install on a project using one of the affected axios versions, your entire system may be compromised. > The malicious versions inject a new dependency, [email protected] , which is never imported anywhere in the axios source code. Its sole purpose is to execute a postinstall script that acts as a cross platform remote access trojan (RAT) dropper, targeting macOS, Windows, and Linux. The dropper contacts a live command and control server and delivers platform specific second stage payloads. After execution, the malware deletes itself and replaces its own package.json with a clean version to evade forensic detection. I strongly recommend you read the entire article.
View on HN · Topics
Completely agree. NPM has the only registry where massive supply chain attacks happen several times a year. Mainly the fault lies with NPM itself, but much of it is just a terrible opsec culture in the community. Most package.jsons I see have semver operators on every dependency, so patches spread incredibly quickly. Package namespacing is not enforced, so there is no way of knowing who the maintainer is without looking it up on the registry first; for this reason many of the most popular packages are basically side projects maintained by a single developer*. Post-install scripts are enabled by default unless you use pnpm or bun. When you combine all these factors, you get the absolute disaster of an ecosystem that NPM is. *Not really the case for Axios as they are at least somewhat organized and financed via sponsors.
View on HN · Topics
The semantics are very relevant, since you presented it as a supply-chain attack. If you call a library vulnerability a supply-chain attack, then your argument has lost coherence. > The OC is somehow under the illusion... Avoiding package managers with shitty policies is the silver bullet for this attack vector. I get that it can be useful in the moment to retract published artifacts, or update them in-place, or run some code after your artifact is downloaded, but all of these are false economies in our hostile environment.
View on HN · Topics
Other languages have package managers (perl) and there are package managers in existence that are not so vulnerable to this issue. IMO, it stems from one place: Transitive dependencies and general opaqueness of the issue. In package managers like pacman, apt, apk,... it's easier to catch such issue. They do have postinstall scripts, but it's part of the submission to the repo, not part of the project. Whatever comes from the project is hashed, and that hash is also visible as part of the submission. That makes it a bit difficult to sneak something. You don't push a change, they pull yours.