mtud

Axios compromised on NPM – Malicious versions drop remote access trojan

https://www.stepsecurity.io/blog/axios-compromised-on-npm-malicious-versions-drop-remote-access-trojan

axios Compromised on npm - Malicious Versions Drop Remote Access Trojan - StepSecurity

Hijacked maintainer account used to publish poisoned axios releases including 1.14.1 and 0.30.4. The attacker injected a hidden dependency that drops a cross platform RAT. We are actively investigating and will update this post with a full technical analysis.

Mar 31 at 2:54amWeb
Show threadjadarMar 31
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.
Show threadrybosomeMar 31

> it’s got me nervous to use Python or Node.js these days

My feelings precisely. Min package age (supported in uv and all JS package managers) is nice but I still feel extremely hesitant to upgrade my deps or start a new project at the moment.

I don’t think this is going to stabilize any time soon, so figuring out how to handle potentially compromised deps is something we will all need to think about.

Show threadTazerenixMar 31

NPM only gained minimum package age in February of this year, and still doesn't support package exclusions for internal packages.

https://github.com/npm/cli/pull/8965

https://github.com/npm/cli/issues/8994

Its good that that they finally got there but....

I would be avoiding npm itself on principle in the JS ecosystem. Use a package manager that has a history of actually caring about these issues in a timely manner.

feat: add min-release-age by wraithgar · Pull Request #8965 · npm/cli

This is a new config that is a way to populate the "before" config using a relative date integer. This deceptively small change was the result of a LOT of work to get to this point, prima...

GitHub
Show threadarcfourMar 31

PNPM makes you approve postinstall scripts instead of running them by default, which helps a lot. Whenever I see a prompt to run a postinstall script, unless I know the package normally has one & what it does, I go look it up before approving it.

(Of course I could still get bitten if one of the packages I trust has its postinstall script replaced.)

Show threadcrimsonnoodle58Mar 31
More like the Trivy incident (which led to the compromise of LiteLLM).
Show threadh4ch1Mar 31

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, [email protected], a package that is never imported anywhere in the axios source, whose only purpose is to run a postinstall script that deploys a cross-platform remote access trojan (RAT)

Good news for pnpm/bun users who have to manually approve postinstall scripts.

Show threadbeartMar 31

> nearly every other project uses it for some reason instead of fetch (I never understood why).

Fetch wasn't added to Node.js as a core package until version 18, and wasn't considered stable until version 21. Axios has been around much longer and was made part of popular frameworks and tutorials, which helps continue to propagate it's usage.

Show threadseerMar 31

Also it has interceptors, which allow you to build easily reusable pieces of code - loggers, oauth, retriers, execution time trackers etc.

These are so much better than the interface fetch offers you, unfortunately.

Show threadreactordevMar 31

You can do all of that in fetch really easily with the init object.

fetch('https://api.example.com/data', {
headers: {
'Authorization': 'Bearer ' + accessToken
}
})

Show threadmhioMar 31
What does an interceptor in the RequestInit look like?
Show threadzdragnarMar 31

There are pretty much two usage patterns that come up all the time:

1- automatically add bearer tokens to requests rather than manually specifying them every single time

2- automatically dispatch some event or function when a 401 response is returned to clear the stale user session and return them to a login page.

There's no reason to repeat this logic in every single place you make an API call.

Likewise, every response I get is JSON. There's no reason to manually unwrap the response into JSON every time.

Finally, there's some nice mocking utilities for axios for unit testing different responses and error codes.

You're either going to copy/paste code everywhere, or you will write your own helper functions and never touch fetch directly. Axios... just works. No need to reinvent anything, and there's a ton of other handy features the GP mentioned as well you may or may not find yourself needing.

Show threadmeekinsMar 31
It also supports proxies which is important to some corporate back-end scenarios
Show threadnathanmillsMar 31
fetch supports proxies
Show threadmartmulxMar 31
Does pnpm block postinstall on transitive deps too or just top-level? We have it configured at work but I've never actually tested whether it catches scripts from packages that get pulled in as sub-dependencies.
Show threaddawnerdMar 31
From what I can tell, it blocks it everywhere.
Show threadarcfourMar 31
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).
Show threadeviksMar 31

> 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)?

Show threadpostalcoderMar 31

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-scripts=true

~/Library/Preferences/pnpm/rc
minimum-release-age=10080 # minutes

~/.bunfig.toml
[install]
minimumReleaseAge = 604800 # seconds


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

If you're developing with LLM agents, you should also update your AGENTS.md/CLAUDE.md file with some guidance on how to handle failures stemming from this config as they will cause the agent to unproductively spin its wheels.

Show threadmhioMar 31

and for yarn berry

~/.yarnrc.yml
npmMinimalAgeGate: "3d"

Show threadXYen0nMar 31
If everyone avoids using packages released within the last 7 days, malicious code is more likely to remain dormant for 7 days.
Show threadcozzydMar 31
that's why people are telling others to use 7 days but using 8 days themselves :)
Show threadotterleyMar 31
What do you base that on? Threat researchers (and their automated agents) will still keep analyzing new releases as soon as they’re published.
Show threadjmward01Mar 31
I suspect most packages will keep a mix of people at 7 days and those with no limit. That being said, adding jitter by default would be good to these features.
Show threadAurornisMar 31

Most people won’t.

7 days gives ample time for security scanning, too.

Show thread3abitonMar 31
This highly depends on the detection mechanism.
Show threadsuperjanMar 31
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”.
Show threadfriendzisMar 31

> (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?

Show threadwpsMar 31

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.

Show threadvsgherziMar 31
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.
Show threadrectangMar 31
Hosting curated dependencies is a commercially valuable service. Eventually an economy arises where people pay vendors to vet packages.
Show threadtankenmateMar 31
It already exists; cloudsmith
Show threadpier25Mar 31

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.

Show threadbrigandishMar 31

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 been doing this from the start, even if I understand why we haven't. The excuses are starting to wear thin though.