Self Propagating NPM Malware Compromises over 40 Packages

Re:Self Propagating NPM Malware Compromises over 40 Packages by spankalee on Tuesday September 16, 2025 @09:44AM (#45262184)

Sandboxing doesn't do any good if the malicious code and target data are in the same sandbox, which is the whole point of these supply-chain attacks.

[ Parent | on HN ]

Re:Self Propagating NPM Malware Compromises over 40 Packages by pixl97 on Tuesday September 16, 2025 @10:40AM (#45262918)

I mean, what does do good if your supply chain is attacked?

This said, less potential vendors supplying packages 'may' reduce exposure, but doesn't remove it.

Either way, not running the bleeding edge packages unless it's a known security fix seems like a good idea.

[ Parent | on HN ]

Re:Self Propagating NPM Malware Compromises over 40 Packages by spankalee on Tuesday September 16, 2025 @02:24PM (#45265911)

The supply chain infrastructure needs to stop being naive and allowing for insecure publishing.

- npm should require 2FA disallow tokens for publishing. This is an option, but it should be a requirement.

- npm should require using a trusted publisher and provenance for package with over 100k downloads a week and their dependencies.

- Github should require a 2FA step for automated publishing

- npm should add a cool down period where if won't install brand new packages without a flag

- npm should stop running postinstall scripts.

- npm should have an option to not install packages without provenance.

[ Parent | on HN ]

Re:Self Propagating NPM Malware Compromises over 40 Packages by raxxorraxor on Tuesday September 16, 2025 @05:57PM (#45268709)

The reality is that for a huge crowd of developers 2FA doesn't do shit.

[ Parent | on HN ]

Re:Self Propagating NPM Malware Compromises over 40 Packages by AlienRobot on Tuesday September 16, 2025 @03:33PM (#45266847)

I think the sandbox they're talking about is the browser, not the server (which runs node).

[ Parent | on HN ]

Re:Self Propagating NPM Malware Compromises over 40 Packages by tetha on Tuesday September 16, 2025 @04:22PM (#45267459)

But if we think about a release publishing chain like a BSD process separation, why do they have to be?

Sure, there will be a step/stage that will require access to NPM publish credentials to publish to NPM. But why does this stage need to execute any code except a very small footprint of vetted code? It should just pickup a packaged, signed binary and move it to NPM.

The compilation/packaging step on the other hand doesn't need publishing rights to NPM. Ideally, it should only get a filesystem with the sources, dependencies and a few shared libraries and /sys or /proc dependencies it may need to function. Why does some dependency downloading need access to your entire filesystem? Maybe it needs some allowed secrets, but eh.

It's certainly a lot of change into existing pipelines and ideas, and it's certainly possible to poke holes into there if you want things to be easy. But it'd raise the bar quite a bit.

[ Parent | on HN ]