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

811–820 of 894 posts

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

#811

Post by croemer »

croemer wrote: post #606

Has anyone else noticed there was a recent sudden flurry of 3000 deleted issues on axios/axios? The jump happened on March 23. Was this a first sign of compromise? Or just coincidence of an AI agent going rogue. There are pretty much exactly 3000 deleted issues, with the range starting at https://github.com/axios/axios/issues/7547 (7547) and ending at https://github.com/axios/axios/issues/10546 (10546 which is 7547+2…

Maintainer replied here https://github.com/axios/axios/discussions/10612

> nope this was just someone bombing the repo throught the API it seemd

> i then just closed and deleted them with a script.. seems it is happening with a couple repos, blocked the users who were doing this

I think it could well have been the attacker trying to hiding any notifications of suspicious activity (email address changed, suspicious login) in the flurry of issue related emails.

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

#813

Post by nedt »

zarzavat wrote: post #534
nedt wrote: post #510

Earlier quoted context omitted.

Before that we had node-fetch. If you already use a dependency why not one that's pretty much what will come natively to every JS runtime soon.

The fetch API is designed for browsers. It's not designed for servers. Fetch may work for a particular use case on the server, it may not. Servers have needs over and above what a browser allows the client to do.

Now I'm curious, because we have a big server side code base using fetch(). What are you using that doesn't work with fetch? Especially since axios nowadays has a fetch adapter.

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

#814

Post by summitwebaudit »

The postinstall script vector is getting all the attention, but IMO the scarier part is how the attacker chain works: compromise one package's credentials, use that access to pivot to the next target. Trivy -> LiteLLM -> now potentially axios. Each compromised package becomes a credential harvester for the next round.\n\nThe min-release-age configs (now in npm, pnpm, bun, uv) are a good start, but they only work as herd immunity — you need enough early adopters installing fresh releases to trigger detection before the 7-day window expires for everyone else. It's basically a bet that security researchers will catch it faster than your cooldown period.\n\nFor Node specifically: if you're still using axios for new projects, it's worth asking why. Native fetch has been stable in Node since v21. One less dependency in your tree is one less attack surface.

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

#816

Post by efilife »

summitwebaudit wrote: post #814

The postinstall script vector is getting all the attention, but IMO the scarier part is how the attacker chain works: compromise one package's credentials, use that access to pivot to the next target. Trivy -> LiteLLM -> now potentially axios. Each compromised package becomes a credential harvester for the next round.\n\nThe min-release-age configs (now in npm, pnpm, bun, uv) are a good start, but they only work as h…

I haven't seen a bot here insert a \n into a comment yet

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

#817

Post by efilife »

staticassertion wrote: post #483
paustint wrote: post #455

Earlier quoted context omitted.

In this case, the author's NPM account was taken over, email address changed to one the attacker controls, and the package was manually published. Since the attacker had full control of the NPM account, it is game over - the attacker can login to NPM and could, if they wanted, configure Trusted Publishing on any repo they control. Axios IS using trusted publishing, but that didn't do anything to prevent the attack si…

Yeah, NPM should be enforcing 2FA and likely phishing resistant 2FA for some packages/ this should be a real control, issuing public audit events for email address changes, and publish events should include information how it was published (trusted publishing, manual publish, etc).

https://docs.npmjs.com/configuring-two-factor-authentication

> Important: Publishing to npm requires either: Two-factor authentication (2FA) enabled on your account, OR A granular access token with bypass 2FA enabled

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

#818

Post by efilife »

xinayder wrote: post #463

Very detailed and props to the security researchers, but the blog post has several indicators that it was written by AI, to which point I suspect their malware analysis was also done by a LLM. I just wish it had more human interaction rather than have a GenAI spit out the blog post. It's very repetitive and includes several EM dashes.

It was in part written by a LLM, but I believe some of the analysis was done by humans. You can just check where there's proper punctuation and em-dashes in the commented code

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

#819

Post by afavour »

apitman wrote: post #745
zachrip wrote: post #546

Earlier quoted context omitted.

Fetch has also lacked support for features that xhr has had for over a decade now. For example upload progress. It's slowly catching up though, upload progress is the only thing I'd choose xhr for.

You can pipe through a TransformStream that counts how many bytes you've uploaded, right?

That would show how quickly the data is passing into the native fetch call but doesn’t account for kind of internal buffer it might have, network latency etc

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

#820

Post by mday-edamame »

woodruffw wrote: post #431

There’s a recurrent pattern with these package compromises: the attacker exfiltrates credentials during an initial phase, then pivots to the next round of packages using those credentials. That’s how we saw them make the Trivy to LiteLLM leap (with a 5 day gap), and it’ll almost certainly be similar in this case. The solution to this is twofold, and is already implemented in the primary ecosystems being targeted (Pyt…

There's another element to the solution here: runtime behavioral analysis. No matter how completely the maintainer's credentials are compromised, no matter how well the malware is concealed, it still has to act like malware (in the case of LiteLLM, credential harvesting, in this case a remote-access Trojan). It's possible to detect the behavior, rather than relying on supply-chain integrity.

We built a free tool that runs local behavior analysis on your machine, it's caught every supply-chain attack in the last couple weeks: https://www.producthunt.com/products/axios-litellm-detector

Post reply on HN