Hacker News Reader

Comment by paulirish | Hacker News Reader

This vulnerability was reported to NPM in 2016: https://blog.npmjs.org/post/141702881055/package-install-scr... https://www.kb.cert.org/vuls/id/319816 but the NPM response was WAI.

View on HN

Acronym expansion for those-not-in-the-know (such as me before a web search): WAI might mean "working as intented", or possibly "why?"

Thank you. It's frustrating when people uncommon acronyms without explaining them.

AI is helpful for this, but I also built https://www.hackterms.com eight years ago for this exact reason.

And of course good old Urban Dictionary: https://www.urbandictionary.com/define.php?term=WAI

Even if we didn't have post install scripts wouldn't the malware just run as soon as you imported the module into your code during the build process, server startup, testing, etc?

I can't think of an instance where I ran npm install and didn't run some process shortly after that imported the packages.

Many people have non-JS backends and only use npm for frontend dependencies. If a postinstall script runs in a dev or build environment it could get access to a lot of things that wouldn't be available when the package is imported in a browser or other production environment.

Malicious client-side code can still perform any user action, exfiltrate user data via cross-domain requests, and probe the user's local network.

I wonder why npm doesn't block pre/postinstall scripts by default, which pnpm and Bun (and I imagine others) already do.

EDIT: oh I scrolled down a bit further and see you said the exact same thing in a top-level comment hahah, my bad

NPM belongs to Microsoft. What do you expect?

NPM was acquired 4 years after that post

Reply on news.ycombinator.com