Live data from Hacker News

Axios compromised on NPM – Malicious versions drop remote access trojan

stepsecurity.io

81–90 of 894 posts

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

#81
post #13

I can't even imagine the scale of the impact with Axios being compromised, nearly every other project uses it for some reason instead of fetch (I never understood why). Also from the report: > Neither malicious version contains a single line of malicious code inside axios itself. Instead, both inject a fake dependency, plain-crypto-js@4.2.1, a package that is never imported anywhere in the axios source, whose only pu…

[flagged]

It prompts for transitive dependencies, too. I have never had workerd as a direct dependency of any project of mine but I get prompted to approve its postinstall script whenever I install cloudflare's wrangler package (since workerd needs to download the appropriate Workers runtime for your platform).

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

#82

I recommend everyone to use bwrap if you're on linux and alias all package managers / anything that has post build logic with it. I have bwrap configured to override: npm, pip, cargo, mvn, gradle, everything you can think of and I only give it the access it needs, strip anything that is useless to it anyway, deny dbus, sockets, everything. SSH is forwarded via socket (ssh-add). This limits the blast radius to your CW…

AFAIK maven doesn’t support post install logic like npm does. You have to explicitly optin with build plugins. It doesn’t let any arbitrary dependency run code on your machine.

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

#83
post #69

Min release age sucks, but we’ve been here before. Email attachments used to just run wild too, then everyone added quarantine delays and file blocking and other frictions... and it eventually kinda/sorta worked. This does feel worse, though, with fewer chokepoints and execution as a natural part of the expectation. Edit: bottom line is installs are gonna get SOOO much more complicated. You can already see the soluti…

Min release age might just postpone vulnerability to be applied few days later in non trivial cases like this. More I think about it, Odin lang approach of no package manager makes senses. But, for that approach won't work for Javascript as it needs npm package even for trivial things. Even vendoring approach like golang won't work with Javascript with the amount of churn and dependencies.

[deleted]

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

#84

It's reasons like this why I refuse to download Node or use anything NPM. Thankfully other languages are better anyways.

Because no other language has ever had supply chain attacks ever, in history. Nope. https://blog.rust-lang.org/2022/05/10/malicious-crate-rustde... https://en.wikipedia.org/wiki/Log4Shell https://blog.pypi.org/posts/2024-12-11-ultralytics-attack-an... https://about.gitlab.com/blog/gitlab-catches-mongodb-go-modu... https://www.reversinglabs.com/blog/packagist-php-repo-supply...

Log4Shell was hardly a supply-chain attack - just a latent bug in a widely-used library. That can happen anywhere.

Maven to this day represents my ideal of package distribution. Immutable versions save so much trouble and I really don't understand why, in the age of left-pad, other people looked at that and said, "nah, I'm good with this."

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

#85
post #70

Not to beat a dead horse but I see this again and again with dependencies. Each time I get more worried that the same will happen with rust. I understand the fat std library approach won’t work but I really still want a good solution where I can trust packages to be safe and high quality.

Hosting curated dependencies is a commercially valuable service. Eventually an economy arises where people pay vendors to vet packages.

It already exists; cloudsmith

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

#86
post #60

There are so many scanners these days these things get caught pretty quick. I think we need either npm or someone else to have a registry that only lets through packages that pass these scanners. Can even do the virustotal thing of aggregating reports by multiple scanners. NPM publishes attestation for trusted build environments. Google has oss-rebuild. All it takes is an `npm config set` to switch registries anyways…

The ones you hear about are caught quickly, I’m more worried about the non obvious ones. So far none of these have been as simple as changing a true to a false and bypassing all auth for all products or something, and would that be caught by an automated scanner?

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

#87

Not to beat a dead horse but I see this again and again with dependencies. Each time I get more worried that the same will happen with rust. I understand the fat std library approach won’t work but I really still want a good solution where I can trust packages to be safe and high quality.

If the fat std library is not viable you can only increase security requirements.

Axios has like 100M downloads per week. A couple of people with MFA should have to approve changes before it gets published.

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

#88

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…

About the use of different units: next time you choose a property name in a config file, include the unit in the name. So not “timeout” but “timeoutMinutes”.

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

#89
post #8

How much do you want to bet me that the credential was stolen during the previous LiteLLM incident? At what point are we going to have to stop using these package managers because it's not secure? I've got to admit, it's got me nervous to use Python or Node.js these days, but it's really a universal problem.

More like the Trivy incident (which led to the compromise of LiteLLM).

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

#90
post #27
post #13

I can't even imagine the scale of the impact with Axios being compromised, nearly every other project uses it for some reason instead of fetch (I never understood why). Also from the report: > Neither malicious version contains a single line of malicious code inside axios itself. Instead, both inject a fake dependency, plain-crypto-js@4.2.1, a package that is never imported anywhere in the axios source, whose only pu…

> Good news for pnpm/bun users who have to manually approve postinstall scripts. Would they not have approved it for earlier versions? But also wouldn't the chance of addition automatic approval be high (for such a widely used project)?

Assuming axios didn't have a postinstall script before, it wouldn't have been approved for a previous version. If you ignore it, you ignore it, but postinstall scripts are relatively rare in npm deps, so it would seem a bit out of place when the warning pops up.
Post reply on HN