Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Axios compromised on NPM – Malicious versions drop remote access trojan

stepsecurity.io

Post reply on HN
Print view View original

831–840 of 894 posts

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#831

Post by Groxx »

hu3 wrote: post #826
Groxx wrote: post #801

Earlier quoted context omitted.

Largely, yes. But also everyone sane avoids the built-in http client in any production setting because it has rather severe footguns and complicated (and limited) ability to control it. It can't be fixed in-place due to its API design... and there is no replacement at this point. The closest we got was adding some support for using a Context, with a rather obtuse API (which is now part of the footgunnery). There's al…

This looks like an ad for batteries included to me. Libraries also don't get it right the first time so they increment minor and major versions. Then why is it not okay for built-in standard libraries to version their functionality also? Just like Go did with JSON? The benefits are worth it judging by how ubiquitous Go, Java and .NET are. I'd rather leverage billions of support paid by the likes of Google, Oracle and…

Third party libraries have been avoiding those json footguns (and significantly improving performance) for well over a decade before stdlib got it. Same with logging. And it's looking like it will be over two decades for an even slightly reasonable http client.

Stuff outside stdlib can, and almost always does, improve at an incomparably faster rate.

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#832

Post by SAI_Peregrinus »

estebank wrote: post #584
physicsguy wrote: post #221

Earlier quoted context omitted.

Rust is terrible for pulling in hundreds of dependencies though. Add tokio as a dependency and you'll get well over 100 packages added to your project.

Even side stepping that tokio no longer pulls multiple packages, it used to be split into multiple packages, in the same way that KDE in Rust would be hundreds of packages. Rust projects tend to take their project and split it into many smaller packages, for ease of development, faster compiles through parallelization, ensuring proper splitting of concerns, and allowing code reuse by others. But the packages are equi…

It's worth noting that Rust packages (crates) are all single compilation units, and every compilation unit is a package. It's the equivalent of complaining that OpenSSL pulls in hundreds of `.c` files.

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#833

Post by [deleted] »

fishpen0 wrote: post #684
EMM_386 wrote: post #456

Earlier quoted context omitted.

This might make things worse not better. Yes - the postinstall hook attack vector goes away. You can do SHA pinning since Git's content addressing means that SHA is the hash of the content. But then your "lockfile" equivalent is just... a list of commit SHAs scattered across import statements in your source? Managing that across a real dependency tree becomes a nightmare. This is basically what Deno's import maps tri…

> But then your "lockfile" equivalent is just... a list of commit SHAs scattered across import statements in your source? Managing that across a real dependency tree becomes a nightmare. The irony is that this is actually the current best practice to defend against supply chain attacks in the github actions layer. Pin all actions versions to a hash. There's an entire secondary set of dev tools for converting GHA vers…

[deleted]

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#834

Post by strogonoff »

KajMagnus wrote: post #810
strogonoff wrote: post #245

Earlier quoted context omitted.

Zero-installs mode does not replace the lockfile. Your lockfile is still the source of truth regarding integrity hashes. However, it’s an extra line of defence against 1) your registry being down (preventing you from pushing a security hotfix when you find out another package compromised your product), 2) package unpublishing attacks (your install step fails or asks you to pick a replacement version, what do you do a…

Good points. But what do you mean with 3: "lockfile poisoning attacks, by making them more complicated" — making the lockfiles more complicated ? Also, 4) Simpler to `git diff` the changes, when you have the source locally already :- )

> making the lockfiles more complicated?

Poor phrasing; I meant the attacks. Now you don’t just have a lockfile you need to sneakily modify, and the diff grows.

As to your second point, yes. It’s really a different feeling when you add one more package and suddenly have 215 new files to check in!

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#835

Post by TheCoelacanth »

hu3 wrote: post #826
Groxx wrote: post #801

Earlier quoted context omitted.

Largely, yes. But also everyone sane avoids the built-in http client in any production setting because it has rather severe footguns and complicated (and limited) ability to control it. It can't be fixed in-place due to its API design... and there is no replacement at this point. The closest we got was adding some support for using a Context, with a rather obtuse API (which is now part of the footgunnery). There's al…

This looks like an ad for batteries included to me. Libraries also don't get it right the first time so they increment minor and major versions. Then why is it not okay for built-in standard libraries to version their functionality also? Just like Go did with JSON? The benefits are worth it judging by how ubiquitous Go, Java and .NET are. I'd rather leverage billions of support paid by the likes of Google, Oracle and…

Libraries don't get it right the first time, but there are often multiple competing libraries which allows more experimentation and finding the right abstraction faster.

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#836

Post by philipwhiuk »

a13n wrote: post #704

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. Th…

pnpm and bun have approved lists.

npm is just dragging it's feet - and stuff like this is why people moved to pnpm, yarn and bun in the first place.

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#837

Post by hunter2_ »

wongarsu wrote: post #575
woodruffw wrote: post #523

Earlier quoted context omitted.

That’s what I mean by calendar units. These aren’t issues if you don’t try to apply durations to the “real” calendar. (This is all in the context of cooldowns, where I’m not convinced the there’s any real ambiguity risk by allowing the user to specify a duration in day or hour units rather than seconds. In that context a day is exactly 24 hours, regardless of what your local savings time rules are.)

"exactly 24 hours" could still be anywhere between 86399 and 86401 seconds, depending on leap seconds. At least if by an hour you mean an interval of 60 minutes, because a minute that contains a leap second will have either 59 or 61 seconds. You could specify that for the purposes of cooldowns you want "hour" to mean an interval of 3600 seconds. But that you have to specify that should illustrate how ambiguous the co…

If you say "wait 1 day without using a calendar+locale" then the duration is unambiguously 86400s, but if you say "wait 1 day using a calendar+locale" or "wait until this time tomorrow" then the duration is ambiguous until you've incorporated rules like leap/DST. I think GP's point is that "wait 1 day" unambiguously defaults to the former, and you disagree, but perhaps it's a reasonable default.

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#838

Post by CountHackulus »

fishpen0 wrote: post #681
afavour wrote: post #370

Earlier quoted context omitted.

Irony is that Node has no need for Axios, native fetch support has been there for years, so in terms of network requests it is batteries included.

It doesn't matter. We pulled axios out of our codebase, but it still ends up in there as a child or peer from 40 other dependencies. Many from major vendors like datadog, slack, twilio, nx (in the gcs-cache extension), etc...

Every time I'm reminded of this article about package managers. https://www.gingerbill.org/article/2025/09/08/package-manage...

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#839

Post by woodruffw »

hunter2_ wrote: post #837
wongarsu wrote: post #575

Earlier quoted context omitted.

"exactly 24 hours" could still be anywhere between 86399 and 86401 seconds, depending on leap seconds. At least if by an hour you mean an interval of 60 minutes, because a minute that contains a leap second will have either 59 or 61 seconds. You could specify that for the purposes of cooldowns you want "hour" to mean an interval of 3600 seconds. But that you have to specify that should illustrate how ambiguous the co…

If you say "wait 1 day without using a calendar+locale" then the duration is unambiguously 86400s, but if you say "wait 1 day using a calendar+locale" or "wait until this time tomorrow" then the duration is ambiguous until you've incorporated rules like leap/DST. I think GP's point is that "wait 1 day" unambiguously defaults to the former, and you disagree, but perhaps it's a reasonable default.

Yep, this is exactly my point. Durations are abstract spans of "stopwatch time," they don't adhere to local times or anything else we use as humans to make time more useful to us. In that context there's no real ambiguity to using units like hours/days/weeks (but not months, etc.) because they have unambiguous durations.

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#840

Post by lukeschlather »

kube-system wrote: post #713
jmull wrote: post #508

Earlier quoted context omitted.

In my experience people feel the need to wrap axios too.

These are the kind of people I hope AI replaces

I have never consciously wrapped Axios or fetch, but a cursory search suggests that there was a time when it was impossible for either to force TLS1.3. It's easy to imagine alternate implementations exist for frivolous reasons, but sometimes there are hard security or performance requirements that force you into them.
Post reply on HN