Live data from Hacker News

Axios compromised on NPM – Malicious versions drop remote access trojan

stepsecurity.io

731–740 of 894 posts

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

#731

Earlier quoted context omitted.

> But if you need to bring in 100 different libs (because you bring in 10 libs which in turn brings in 10 libs So don’t? With manual deps management, everyone soon gravitates to a core set of deps. And libraries developer tends to reduce their deps needs, That’s why you see most C libraries deals with file formats, protocols, and broad concerns. Smaller algorithms can be shared with gists and blog articles.

> Smaller algorithms can be shared with gists and blog articles You just invented a worse Stack Overflow. Using libraries is good, actually.

Like is-even or leftpad?

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

#732
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

AI was trained on Axios wrappers, so it's just going to be wrappers all the way down. Look inside any company "API Client" and it's just a branded wrapper around Axios.

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

#734

Earlier quoted context omitted.

Everyone has forgotten standard ISO 8601 durations and invented their own syntax.

uv supports it, https://docs.astral.sh/uv/reference/settings/#exclude-newer

Perfect

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

#735
post #151

In light of these nonstop supply chain attacks: Tonight I created /supply-chain-audit -- A simple claude code skill that fetches info on the latest major package vulnerability, then scans your entire ~/ and gives you a report on all your projects. https://github.com/IsaacGemal/claude-skills It's a bit janky right now but I'd be interested to hear what people think about it.

That sounds terrifying. Stay out of my ~/ thank you very much.

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

#736
# If you have a projects folder containing multiple projects on macOS, you can run this script to recursively scan all subfolders for vulnerable axios versions and the presence of plain-crypto-js, helping you quickly identify potentially affected projects:

find . -name "package.json" -exec sh -c ' dir=$(dirname "{}") echo "==== $dir ====" cd "$dir" npm list axios 2>/dev/null | grep -E "1\.14\.1|0\.30\.4" grep -A1 "\"axios\"" package-lock.json 2>/dev/null | grep -E "1\.14\.1|0\.30\.4" [ -d node_modules/plain-crypto-js ] && echo "POTENTIALLY AFFECTED" ' \;

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

#737
post #501

Earlier quoted context omitted.

Probably went with the simplest implementation, if starting from the current “seconds since epoch” value. Let the user do any calculations needed to translate three days into that measurement. It also efficiently annoys the most people at once: those what want hours will complain if they set it to days, thought that want days will complain if hours are used. By using minutes or seconds you can wind up both segments w…

I'm old enough to remember computers being pitched as devices that can do tedious math for us. Now we have to do tedious math for them apparently.

No no no, see now we just say "computer! do tedious math!", and it will do some slightly different math for us and compliment us on having asked it to do so.

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

#738

Earlier quoted context omitted.

Hi, security here. We've tried, but the amount of people you need for this vs the amount of people you have trying to review and click the big button always means that this step will be a bottleneck. Thus this step will be eliminated. A much better approach would be to pin the versions used and do intentional updates some time after release, say a sprint after.

Pinning, escrowing, and trailing all help, but I'm not sure "this step will be eliminated" is inevitable. Package manager ecosystems are highly centralized. npm.org could require MFA (or rate limit, or email verification, or whatever) and most packagers would gripe but go along with this. A minority would look for npm competitors that didn't have this requirement, and another minority would hack/automate MFA and remo…

Let me rephrase - manual security verification is a velocity blocker. People won't do manual security verification of changes.

I agree that npm.org requiring MFA is a good idea in general and in this case.

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

#739

Earlier quoted context omitted.

What type of developer chooses UX and performance over security? So reckless. I removed the locks from all the doors, now entering/exiting is 87% faster! After removing all the safety equipment, our vehicles have significantly improved in mileage, acceleration and top speed!

Better developer UX can directly lead to better safety. "You are holding it wrong" is a frequent source of security bugs, and better UX reduces the ways you can hold it wrong, or at least makes you more likely to hold it the right way

> Better developer UX can directly lead to better safety.

Depends. If you had to add to a Makefile for your dependencies, you sure as hell aren't going to add 5k dependencies manually just to get a function that does $FOO; you'd write it yourself.

Now, with AI in the mix, there's fewer and fewer reasons to use so many dependencies.

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

#740

Earlier quoted context omitted.

Hi, security here. We've tried, but the amount of people you need for this vs the amount of people you have trying to review and click the big button always means that this step will be a bottleneck. Thus this step will be eliminated. A much better approach would be to pin the versions used and do intentional updates some time after release, say a sprint after.

Yeah, I am looking at that on the use end. It sounds like on the python side this type of thing will be more standard (uv now and soon pip supported with version date requirements). I think time is a big missing element in many security in depth decisions. It can be time until you adopt like use no package newer than xx days or time it takes to deploy etc etc. Unfortunately the ecosystem is getting really diverse and…

Yes, that's why I recommend intentional updates. Planning at least a sprint later gives you a week or two, hoping the community catches such issues.
Post reply on HN