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

91–100 of 894 posts

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

#91

Post by brigandish »

vsgherzi wrote: post #63

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.

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.

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

#92

Post by 3abiton »

XYen0n wrote: post #58
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…

If everyone avoids using packages released within the last 7 days, malicious code is more likely to remain dormant for 7 days.

This highly depends on the detection mechanism.

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

#93

Post by yoyohello13 »

This is just going to get worse and worse as agentic coding gets better. I think having a big dependency tree may be a thing of the past in the coming years. Seems like eventually new malware will be coming out so fast it will basically be impossible to stop.

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

#95

Post by peddling-brink »

nathanmills wrote: post #67
p1mrx wrote: post #25

Earlier quoted context omitted.

Stop trying to make Fetch happen.

No, I will not stop trying to create a more standardized and secure software ecosystem.

The comment you replied to is a quote from the movie Mean Girls.

https://knowyourmeme.com/memes/stop-trying-to-make-fetch-hap...

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

#97

Post by zdragnar »

reactordev wrote: post #21
seer wrote: post #18

Earlier quoted context omitted.

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.

You can do all of that in fetch really easily with the init object. fetch('https://api.example.com/data', { headers: { 'Authorization': 'Bearer ' + accessToken } })

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.

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

#98

Post by friendzis »

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…

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

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

#99

Post by WD-42 »

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…

Props to uv for actually using the correct config path jfc what is “bunfig”

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

#100

Post by imInGoodCompany »

waterTanuki wrote: post #31
slopinthebag wrote: post #5

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 not a supply chain attack.
Post reply on HN