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

181–190 of 894 posts

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

#181

Post by semi-extrinsic »

wps wrote: post #50

Genuinely how are you supposed to make sure that none of the software you have on your system pulls this in? It’s things like this that make me want to swap to Qubes permanently, simply as to not have my password manager in the same context as compiling software ever.

We run everything NPM related inside Apple containers, and are looking to do the same with Python and Rust soon. Bwrap on Linux does the same.

I like to think of it like working with dangerous chemicals in the lab. Back in the days, people were sloppy and eventually got cancer. Then dangers were recognized and PPE was developed and became a requirement.

We are now at the stage in software development where we are beginning to recognizing the hazards and developing + mandating use of proper PPE.

A couple of years ago, pip started refusing to install packages outside of a virtualenv. I'm guessing/hoping package managers will start to have an opt-in flag you can set in a system-wide config file, such that they refuse to run outside of a sandbox.

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

#182

Post by pie_flavor »

nananana9 wrote: post #114

Package managers are a failed experiment. We have libraries like SQLite, which is a single .c file that you drag into your project and it immediately does a ton of incredibly useful, non-trivial work for you, while barely increasing your executable's size. The issue is not dependencies themselves, it's transitive ones. Nobody installs left-pad or is-even-number directly, and "libraries" like these are the vast majori…

Rust libraries are infrequently used outside of Rust because if you have the option, you'd just use Rust, not the ancient featureless language intrinsically responsible for 70% of all security issues. C libraries are infrequently used in Rust outside of system libc, for the same reason; I go and toggle the reqwest switch to use rustls every time, because OpenSSL is horrendous. This is also why you say 'rarely' instead of 'never', when a few years ago it was 'never'; a few years from now you'll say 'uncommonly', and so on. The reason C libraries are used is because you don't feel like reimplementing it yourself, and they are there; but that doesn't apply more to C libraries than Rust libraries, and the vast majority of crates.io wouldn't be usefully represented in C anyway, or would take longer to bind to than to rewrite. (No, nobody uses libcurl.) Finally, this only happens in NPM, and the Rust libraries you pull in are all high-quality. So this sounds like a bunch of handwaving about nonsense.

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

#183

Post by lepuski »

I believe compartmentalized operating systems like Qubes are the future for defending against these kinds of attacks.

Storing your sensitive data on a single bare-metal OS that constantly downloads and runs packages from unknown maintainers is like handing your house key out to a million people and hoping none of them misuse it.

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

#184

Post by js2 »

umko21 wrote: post #169
ad3xyz wrote: post #133

Earlier quoted context omitted.

https://docs.astral.sh/uv/concepts/resolution/#dependency-co... > Define a dependency cooldown by specifying a duration instead of an absolute value. Either a "friendly" duration (e.g., 24 hours, 1 week, 30 days) or an ISO 8601 duration (e.g., PT24H, P7D, P30D) can be used.

My bad. This works for per project configuration, but not for global user configuration.

I think it should work at the user config level too:

> If project-, user-, and system-level configuration files are found, the settings will be merged, with project-level configuration taking precedence over the user-level configuration, and user-level configuration taking precedence over the system-level configuration.

https://docs.astral.sh/uv/concepts/configuration-files/

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

#185

Post by Hackbraten »

tick_tock_tick wrote: post #101
brigandish wrote: post #91

Earlier quoted context omitted.

An alternative: - copy the dependencies' tests into your own tests - copy the code in to your codebase as a library using the same review process you would for code from your own team - treat updates to the library in the same way you would for updates to your own code Apparently, this extra work will now not be a problem, because we have AI making us 10x more efficient. To be honest, even without AI, we should've be…

I don't know where you've worked but a hostile and intelligent actor or internal red team would succeed under each of those cases at every job I've worked at.

Defending against a targeted attack is difficult, yes. But these recent campaigns were all directed at everyone. Auditing and inspecting your dependencies does absolutely help thwart that because there will always be people who don't.

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

#186

Post by novachen »

postalcoder wrote: post #26

PSA: npm/bun/pnpm/uv now all support setting a minimum release age for packages. I also have `ignore-scripts=true` in my ~/.npmrc. Based on the analysis, that alone would have mitigated the vulnerability. bun and pnpm do not execute lifecycle scripts by default. Here's how to set global configs to set min release age to 7 days: ~/.config/uv/uv.toml exclude-newer = "7 days" ~/.npmrc min-release-age=7 # days ignore-scr…

[dead]

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

#187

Post by mcintyre1994 »

The frustrating thing here is that axios versions display on npmjs with verified provenance. But they don’t use trusted publishing: https://github.com/axios/axios/issues/7055 - meaning the publish token can be stolen.

I wrongly thought that the verified provenance UI showed a package has a trusted publishing pipeline, but seems it’s orthogonal.

NPM really needs to move away from these secrets that can be stolen.

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

#188

Post by Hackbraten »

I am now migrating all my unencrypted secrets on my machines to encrypted ones. If a tool supports scripted credential providers (e.g. aws-cli or Ansible), I use that feature. Otherwise, I wrap the executable with a script that runs gpg --decrypt and injects an environment variable.

That way, I can at least limit the blast radius when (not if) I catch an infostealer.

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

#189

Post by friendzis »

gib444 wrote: post #140
friendzis wrote: post #98

Earlier quoted context omitted.

> (Side note, it's wild that npm, bun, and pnpm have all decided to use different time units for this configuration.) First day with javascript?

OP should be glad a new time unit wasn't invented

Workdays! Think about it, if you set the delay in regular days/seconds the updated dependency can get pulled in on a weekend with only someone maybe on-call.

(Hope your timezones and tzdata correctly identifies Easter bank holiday as non-workdays)

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

#190

Post by notpushkin »

mort96 wrote: post #176
layer8 wrote: post #149

Earlier quoted context omitted.

Or require the value to specify a unit.

At that point, you're making all your configuration fields strings and adding another parsing step after the json/toml/yaml parser is done with it. That's not ideal either; either you write a bunch of parsing code (not terribly difficult but not something I wanna do when I can just not), or you use some time library to parse a duration string, in which case the programming language and time library you happen to use…

TOML has a datetime type (both with or without tz), as well as plain date and plain time:

  start_at = 2026-05-27T07:32:00Z  # RFC 3339
  start_at = 2026-05-27 07:32:00Z  # readable
We should extend it with durations:

  timeout = PT15S  # RFC 3339
And like for datetimes, we should have a readable variant:

  timeout = 15s   # can omit "P" and "T" if not ambiguous, can use lowercase specifiers
Edit: discussed in detail here: https://github.com/toml-lang/toml/issues/514
Post reply on HN