Github / Microsoft could easily fix this, couldn't they? Leaving NPM up in its current state seems criminal, especially since LLMs generate NPM commands so frequently.
replyThey have some changes here in v12: https://github.blog/changelog/2026-06-09-upcoming-breaking-c...
replyAnd the discussion here, with 215 comments: https://news.ycombinator.com/item?id=48467705
replydeleted
replyIs it possible to fix it in a backwards compatible way? Removing lifecycle scripts is at least a semver major change, and would complicate existing projects relying on packages with lifecycle scripts from upgrading.
replyThis is a real world trolley problem scenario. You can break workflows or you can let everyone get pwned by supply chain attacks. Which is the greater harm?
replyPeople will not adopt a safer version if it broke their workflows. Adoption is part of preventing supply chain attacks.
replyThey will if it's the only version. Eventually.
replydeleted
reply> Friends don't let friends ise NPM
replyor linkedin
I don't have friends, therefore I must use LinkedIn to get a job. Hooray!
replyI know you are joking, but there is something about this that I really don't get. "Friends" here really means "a professional network". Many nerds despise having one or maintaining/building one. At the same time, people pour weeks/months/years of their life into optimizing their modest investment portfolios. 0.01 percentage points of yearly cost differences of some passive ETF. That surely compounds. But you know what also compounds? Knowing somebody who knows somebody who has $skill or $job_posting. In a big way. Your work comp is still the biggest source of income for most, but investing into optimizing it by broadening your network is something people don't want to do. They'd rather discuss the tax implications of nuances of some investment portfolio.
replyI don't disagree, but broadening your network is a very different skill (being social) than handling investment portfolios. And for some of us, it's not that we necessarily despise creating or maintaining a network, it's that we suck at it.
reply>These tools with arbitrary code execution when trying to download some code have got to stop
replyBut you still end up with the code on your machine and risk it being ran.
Bigger issue is giant, inscrutible dependency trees.
In this example, if they tried to run the test suite or application, they'd have been in the same boat.
Afaik all or most languages have some way to run arbitrary code at install time but it seems node is the main one getting targeted. I think the bigger issue here is just people running untrusted things.
Claude Code regularly installs dependencies using (p)npm after I e.g. pull a company main branch to get in sync with my teammates. That happens often. So I pull, Claude edits some code as you requested and it should pass because Claude did alright, but your local box has out-of-date deps. So then Claude runs (p)npm i and now we have automatic exploitation of this gaping hole in npm given extremely common and current AI tooling. Someone has to figure out how to stop AI from running that command or NPM needs to stop that behavior, and I guarantee you it will be easier to get one tool to change than all AI.
replyThe lockfile should protect you there. It'd only be an issue if you're working on updating dependencies in which case there's other protection like min-release-age
replyIf pulling down your company repo and running `npm install` can lead to a compromise, something has went terribly wrong with your company's security setup.
deleted
replyI agree, but I’d extend that to any language using a package manager at this point. “A little copying is better than a little dependency” even more correct now.
replyAll my current projects have all the code needed in the repo (unless impossible, and aside from a compiler which I guess could also be compromised)
IYKYK
replydeleted
reply