[codemonkey-zeta]

I'm coming to the unfortunate realizattion that supply chain attacks like this are simply baked into the modern JavaScript ecosystem. Vendoring can mitigate your immediate exposure, but does not solve this problem.

These attacks may just be the final push I needed to take server rendering (without js) more seriously. The HTMX folks convinced me that I can get REALLY far without any JavaScript, and my apps will probably be faster and less janky anyway.

[jeswin]

Traditional JS is actually among the safest environments ever created. Every day, billions of devices run untrusted JS code, and no other platform has seen sandboxed execution at such scale. And in nearly three decades, there have been very few incidents of large successful attacks on browser engines. That makes the JS engine derived from browsers the perfect tool to build a server side framework out of.

However, processes and practices around NodeJS and npm are in dire need of a security overhaul. leftpad is a cultural problem that needs to be addressed. To start with, snippets don't need to be on npm.

[spankalee]

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.

[lenerdenator]

> Traditional JS is actually among the safest environments ever created.

> However, processes and practices around NodeJS and npm are in dire need of a security overhaul. leftpad is a cultural problem that needs to be addressed. To start with, snippets don't need to be on npm.

Traditional JS is the reason we have all of these problems around NodeJS and npm. It's a lot better than it was, but a lot of JS tooling came up in the time when ES5 and older were the standard, and to call those versions of the language lacking is... charitable. There were tons of things that you simply couldn't count on the language or its standard library to do right, so a culture of hacks and bandaids grew up around it. Browser disparities didn't help either.

Then people said, "Well, why don't we all share these hacks and bandaids so that we don't have to constantly reinvent the wheel?", and that's sort of how npm got its start. And of course, it was the freewheeling days of the late 00s/early 10s, when you were supposed to "move fast and break things" as a developer, so you didn't have time to really check if any of this was secure or made any sense. The business side wanted the feature and they wanted it now.

The ultimate solution would be to stop slapping bandaids and hacks on the JS ecosystem by making a better language but no one's got the resolve to do that.

[WD-42]

Javascript doesn't have a standard library, until it does the 170 million[1] weekly downloads of packages like UUID will continue. You can't expect people to re-write everything over and over.

[1]https://www.npmjs.com/package/uuid

[kortilla]

None of those security guarantees matter when you take out the sandbox, which is exactly what server-side JS does.

The isolated context is gone and a single instance of code talking to an individual client has access to your entire database. It’s a completely different threat model.

[skydhash]

I think the smallest C library I’ve seen was a single file to include on your project if you want terminal control like curses on windows. A lot of libraries on npm (and cargo) should be gist or a blog post.

[mewpmewp2]

Interestingly AI should be able to help a lot with desire to load those snippets.

What I'm wondering if it would help the ecosystem, if you were able to rather load raw snippets into your codebase, and source control as opposed to having them as dependencies.

So e.g. shadcn component pasting approach.

For things like leftPad, cli colors and others you would just load raw typescript code from a source, and there you would immediately notice something malicious or during code reviews.

You would leave actual npm packages to only actual frameworks / larger packages where this doesn't make sense and expect higher scrutiny, multi approvals of releases there.

[lucideer]

> I'm coming to the unfortunate realizattion that supply chain attacks like this are simply baked into the modern JavaScript ecosystem.

I see this odd take a lot - the automatic narrowing of the scope of an attack to the single ecosystem it occurred in most recently, without any real technical argument for doing so.

What's especially concerning is I see this take in the security industry: mitigations put in place to target e.g. NPM, but are then completely absent for PyPi or Crates. It's bizarre not only because it leaves those ecosystems wide open, but also because the mitigation measures would be very similar (so it would be a minimal amount of additional effort for a large benefit).

[woodruffw]

Could you say more about what mitigations you’re thinking of?

I ask because think the directionality is backwards here: I’ve been involved in packaging ecosystem security for the last few years, and I’m generally of the opinion that PyPI has been ahead of the curve on implementing mitigations. Specifically, I think widespread trusted publishing adoption would have made this attack less effective since there would be fewer credentials to steal, but npm only implemented trusted publishing recently[1]. Crates also implemented exactly this kind of self-scoping, self-expiring credential exchange ahead of npm.

(This isn’t to malign any ecosystem; I think people are also overcorrect in treating this like a uniquely JavaScript-shaped problem.)

[1]: https://github.blog/changelog/2025-07-31-npm-trusted-publish...

[simiones]

Most people have addressed the package registry side of NPM.

But NPM has a much, much bigger problem on the client side, that makes many of these mitigations almost moot. And that is that `npm install` will upgrade every single package you depend on to its latest version that matches your declared dependency, and in JS land almost everyone uses lax dependency declarations.

So, an attacker who simply publishes a new patch version of a package they have gained access to will likely poison a good chunk of all of the users of that package in a relatively short amount of time. Even if the projects using this are careful and use `npm ci` instead of `npm install` for their CI builds, it will still easily get developers to download and run the malicious new version.

Most other ecosystems don't have this unsafe-by-default behavior, so deploying a new malicious version of a previously safe package is not such a major risk as it is in NPM.

[kees99]

I agree other repos deserve a good look for potential mitigations as well (PyPI too, has a history of publishing malicious packages).

But don't brush off "special status" of NPM here. It is unique in that JS being language of both front-end and back-end, it is much easier for the crooks to sneak in malware that will end up running in visitor's browser and affect them directly. And that makes it a uniquely more attractive target.

[weinzierl]

Which mitigations specifically are in npm but not in crates.io?

As far as I know crates.io has everything that npm has, plus

- strictly immutable versions[1]

- fully automated and no human in the loop perpetual yanking

- no deletions ever

- a public and append only index

Go modules go even further and add automatic checksum verification per default and a cryptographic transparency log.

Contrast this with docker hub for example, where not even npm's basic properties hold.

So, it is more like

docker hub ⊂ npm ⊂ crates.io ⊂ Go modules

[1] Nowadays npm has this arguably too

[WD-42]

I mostly agree. But NPM is special, in that the exposure is so much higher. The hypothetical python+htmx web app might have 10s of dependencies (including transitive) whereas your typical Javascript/React will have 1000s. All an attacker needs to do is find one of many packages like TinyColor or Leftpad or whatever and now loads of projects are compromised.

[jacques_chester]

Most of the biggest repositories already cooperate through the OpenSSF[0]. Last time I was involved in it, there were representatives from npm, PyPI, Maven Central, Crates and RubyGems. There's also been funding through OpenSSF's Alpha-Omega program for a bunch of work across multiple ecosystems[1], including repos.

[0] https://github.com/ossf/wg-securing-software-repos

[1] https://alpha-omega.dev/grants/grantrecipients/

[worik]

The Rust folks are in denial about this

[reactordev]

Until you go get malware

Supply chain attacks happen at every layer where there is package management or a vector onto the machine or into the code.

What NPM should do if they really give a shit is start requiring 2FA to publish. Require a scan prior to publish. Sign the package with hard keys and signature. Verify all packages installed match signatures. Semver matching isn’t enough. CRC checks aren’t enough. This has to be baked into packages and package management.

[lycopodiopsida]

> Until you go get malware

While technically true, I have yet to see Go projects importing thousands of dependencies. They may certainly exist, but are absolutely not the rule. JS projects, however...

We have to realize, that while supply chain attacks can happen everywhere, the best mitigations are development culture and solid standard library - looking at you, cargo.

I am a JS developer by trade and I think that this ecosystem is doomed. I absolutely avoid even installing node on my private machine.

[HillRat]

Sign the package with hard keys and signature.

That's really the core issue. Developer-signed packages (npm's current attack model is "Eve doing a man-in-the-middle attack between npm and you," which is not exactly the most common threat here) and a transparent key registry should be minimal kit for any package manager, even though all, or at least practically all, the ecosystems are bereft of that. Hardening API surfaces with additional MFA isn't enough; you have to divorce "API authentication" from "cryptographic authentication" so that compromising one doesn't affect the other.

[rs999gti]

> What NPM should do if they really give a shit is start requiring 2FA to publish.

How does 2FA prevent malware? Anyone can get a phone number to receive a text or add an authenticator to their phone.

I would argue a subscrption model for 1 EUR/month would be better. The money received could pay for certification of packages and the credit card on file can leverage the security of the payments system.

[psychoslave]

How will multi-factor-authentication prevent such a supply chain issue?

That is, if some attacker create some dummy trivial but convenient package and 2 years latter half the package hub depends on it somehow, the attacker will just use its legit credential to pown everyone and its dog. This is not even about stilling credentials. It’s a cultural issue with bare blind trust to use blank check without even any expiry date.

https://en.wikipedia.org/wiki/Trust,_but_verify

[cxr]

If NPM really cared, they'd stop recommending people use their poorly designed version control system that relies on late-fetching third-party components required by the build step, and they'd advise people to pick a reliable and robust VCS like Git for tracking/storing/retrieving source code objects and stick to that. This will never happen.

NPM has also been sending out nag emails for the last 2+ years about 2FA. If anything, that constituted an assist in the attack on the Junon account that we saw a couple weeks ago.

[floydnoel]

NPM does require 2FA to publish. I would love a workaround! Isn't it funny that even here on HN, misinformation is constantly being spread?

[hoppp]

They are. Any language that depends heavily on package managers and lacks a standard lib is vulnerable to this.

At some point people need to realize and go back to writing vanilla js, which will be very hard.

The rust ecosystem is also the same. Too much dependence on packages.

An example of doing it right is golang.

[simiones]

The solution is not to go back to vanilla JS, it's for people to form a foundation and build a more complete utilities library for JS that doesn't have 1000 different dependencies, and can be trusted. Something like Boost for C++, or Apache Commons for Java.

[rs186]

Python and Rust both have decent std lib, but it is just a matter of time before this happens in thoae ecosystems. There is nothing unique about this specific attack that could only happen in JavaScript.

[pixl97]

>and go back to writing vanilla js

Lists of things that won't happen. Companies are filled with node_modules importers these days.

Even worse, now you have to check for security flaws in that JS that's been written by node_modules importers.

That or there could someone could write a standard library for JS?

[joquarky]

Some of us are fortunate to have never left vanilla JS.

Of course that limits my job search options, but I can't feel comfortable signing off on any project that includes more dependencies than I can count at a glance.

[BrouteMinou]

C#, Java, and so on.

[jddj]

Is the difference between the number of dev dependencies for eg. VueJs (a JavaScript library for marshalling Json Ajax responses into UI) and Htmx (a JavaScript library for marshalling html Ajax responses into UI) meaningful?

There is a difference, but it's not an order of magnitude and neither is a true island.

Granted, deciding not to use JS on the server is reasonable in the context of this article, but for the client htmx is as much a js lib with (dev) dependencies as any other.

https://github.com/bigskysoftware/htmx/blob/master/package.j...

https://github.com/vuejs/core/blob/main/package.json

[yawaramin]

Except that htmx's recommended usage is as a single <script> injected directly into your HTML page, not as an npm dependency. So unless you are an htmx contributor you are not going to be installing the dev dependencies.

[tarruda]

AFAICT, the only thing this attack relies on, is the lack of scrutiny by developers when adding new dependencies.

Unless this lack of scrutiny is exclusive to JavaScript ecosystem, then this attack could just as well have happened in Rust or Golang.

[coldpie]

I don't know Go, but Rust absolutely has the same problem, yes. So does Python. NPM is being discussed here, because it is the topic of the article, but the issue is the ease with which you can pull in unvetted dependencies.

Languages without package managers have a lot more friction to pull in dependencies. You usually rely on the operating system and its package-manager-humans to provide your dependencies; or on primitive OSes like Windows or macOS, you package the dependencies with your application, which involves integrating them into your build and distribution systems. Both of those involve a lot of manual, human effort, which reduces the total number of dependencies (attack points), and makes supply-chain issues like this more likely to be noticed.

The language package managers make it trivial to pull in dozens or hundreds of dependencies, straight from some random source code repository. Your dependencies can add their own dependencies, without you ever knowing. When you have dozens or hundreds of unvetted dependencies, it becomes trivial for an attacker to inject code they control into just one of those dependencies, and then it's game over for every project that includes that one dependency anywhere in their chain.

It's not impossible to do that in the OS-provided or self-managed dependency scenario, but it's much more difficult and will have a much narrower impact.

[user34283]

There is little point in you scrutinizing new dependencies.

Many who claim to fully analyze all dependencies are probably lying. I did not see anyone in the comments sharing their actual dependency count.

Even if you depend only on Jest - Meta's popular test runner - you add 300 packages.

Unless your setup is truly minimalistic, you probably have hundreds of dependencies already, which makes obsessing over some more rather pointless.

[zelphirkalt]

At least in the JS world there are more people (often also more inexperienced people) who will add a dependency willy-nilly. This is due to many people starting out with JS these days.

[hsbauauvhabzb]

JavaScript does have some pretty insane dependency trees. Most other languages don’t have anywhere near that level of nestedness.

[tomjen3]

That, and the ability to push an update without human interaction.

[qudat]

The blast radius is made far worse by npm having the concept of "postinstall" which allows any package the ability to run a command on the host system after it was installed.

This works for deps of deps as well, so anything in your node_modules has access to this hook.

It's a terrible idea and something that ought to be removed or replaced by something much safer.

[zarzavat]

I agree in principle, but child_process is a thing so I don't think it makes much difference. You are pwned either way if the package can ever execute code.

[jmull]

Simply avoiding Javascript won't cut it.

While npm is a huge and easy target, the general problem exists for all package repositories. Hopefully a supply chain attack mitigation strategy can be better than hoping attackers target package repositories you aren't using.

While there's a culture prevalent in Javascript development to ignore the costs of piling abstractions on top of abstractions, you don't have to buy into it. Probably the easiest thing to do is count transitive dependencies.

[yawaramin]

> Simply avoiding Javascript won't cut it.

But it will cut a large portion of it.

[everdrive]

Javascript is badly over-used and over-depended on. So many websites just display text and images, but have extremely heavy javascript libraries because that's what people know and that is part of the default, and because it enables all the tracking that powers the modern web. There's no benefit to the user, and we'd be better off without these sites existing if there were really no other choice but to use javascript.

[mrweasel]

NPM does seem vastly over represented in these type of compromises, but I don't necessarily think that e.g. pypi is much better in terms of security. So you could very well be correct that NPM is just a nicer, perhaps bigger, target.

If you can sneak malware into a JavaScript application that runs in millions of browsers, that's a lot more useful that getting a some number servers running a module as part of a script, who's environment is a bit unknown.

Javascript really could do with a standard library.

[spoiler]

> So many websites just display text and images

Eh... This over-generalises a bit. That can be said of anything really, including native desktop applications.

[petcat]

Rendering template partials server-side and fetching/loading content updates with HTMX in the browser seems like the best of all worlds at this point.

[koakuma-chan]

Until you need to write JavaScript?

[ZYbCRq22HbJ2y7]

> These attacks may just be the final push I needed to take server rendering (without js) more seriously

Have fun, seems like a misguided reason to do that though.

A. A package hosted somewhere using a language was compromised!

B. I am not going to program in the language anymore!

I don't see how B follows A.

[Aeolun]

Why is this inevitable? If you use only easily verifyable packages you’ve lost nothing. The whole concept of npm automatically executing postinstall scripts was fixed when my pnpm started asking me every time a new package wanted to do that.

[philipwhiuk]

HTMX is full of JavaScript. Server-side-rendering without JavaScript is just back to the stuff Perl and PHP give you.

[bdcravens]

I don't think the point is to avoid Javascript, but to avoid depending on a random number of third-parties.

> Server-side-rendering without JavaScript is just back to the stuff Perl and PHP give you.

As well as Ruby, Python, Go, etc.

[norman784]

HTMX does not have external dependencies, only dev dependencies, reducing the attack surface.

[hosh]

Do you count LiveView (Elixir) in that assessment?

[EMM_386]

> The HTMX folks convinced me that I can get REALLY far without any JavaScript

HTMX is JavaScript.

Unless you meant your own JavaScript.

[yawaramin]

When we say 'htmx allows us to avoid JavaScript', we mean two things: (1) we typically don't need to rely on the npm ecosystem, because we need very few (if any) third-party JavaScript libraries; and (2) htmx and HTML-first allow us to avoid writing a lot of custom JavaScript that we would have otherwise written.

[junon]

This is going to become an issue for a lot of managers, not just npm. Npm is clearly a very viable target right now, though. They're going to get more and more sophisticated.

[kubafu]

Took that route myself and I don't regret it. Now I can at least entirely avoid Node.js ecosystem.

[brazukadev]

Not for the frontend. esm modules work great nowadays with import maps.

[rs999gti]

> supply chain attacks

You all really need to stop using this term when it comes to OSS. Supply chain implies a relationship, none of these companies or developers have a relationship with the creators other than including their packages.

Call it something like "free code attacks" or "hobbyist code attacks."

[shermantanktop]

“code I picked up off the side of the road”

“code I somehow took a dependency on when copying bits of someone’s package.json file”

“code which showed up in my lock file and I still don’t know how it got there”

[__alexs]

I know CrowdStrike have a pretty bad reputation but calling them hobbyists is a bit rude.

[pixl97]

A supply chain can have hobbyists, there's no particular definition that says everyone involved must be a professional registered business.