Live data from Hacker News

Axios compromised on NPM – Malicious versions drop remote access trojan

stepsecurity.io

791–800 of 894 posts

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

#791
post #775

Earlier quoted context omitted.

This is really interesting, thanks for sharing. Great food for thought. Being tightly coupled with MS already, did you ever explore .NET?

We used to have some C# but we moved away from it to have fewer languages and because it was a worse fit for us than Go and Python. I'm not sure .NET would really give us any advantages though. Microsoft treats most major languages as first class citizens in Azure, and since we build everything to be sort of platform agnostic, we wouldn't have the tie-ins that you could have with .NET. I'm not saying it would be fun…

Thanks for taking the time, I really appreciate the insights.

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

#792

I've been advocating to minimize the number of dependencies for some time now. Once you've maintained an open source project for several years, you start to understand the true cost of dependencies and you actually start to pay attention to the people behind the libraries. Popularity doesn't necessarily mean reliable or trustworthy or secure.

I started a project on Expo recently and my god, a thousand dependencies later, it was running.

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

#793
post #769
post #723

Earlier quoted context omitted.

The HTML "Living Standard" is constantly updated [1-6]. The PNG spec [7] has been updated several times in 1996, 1998, 1999, and 2025. The XPath spec [8] has multiple versions: 1.0 (1999), 2.0 (2007), 3.0 (2014), and 3.1 (2017), with 4.0 in development. The RDF spec [9] has multiple versions: 1.0 (2004), and 1.1 (2014). Plus the related specs and their associated versions. The schema.org metadata standard [10] is und…

please! nobody uses Xpath (coz json killed XML), it RDF (semantic web never happened, and one ever 10years is not fast), schema.org (again, nobody cares), PNG: no change in the last 26 years, not fast. the HTML "living standard" :D completely optional and hence not a standard but definition.

Xpath is still used for e2e tests and things like scraping. Especially when there aren't better selectors available.

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

#794

Earlier quoted context omitted.

Irony is that Node has no need for Axios, native fetch support has been there for years, so in terms of network requests it is batteries included.

It doesn't matter. We pulled axios out of our codebase, but it still ends up in there as a child or peer from 40 other dependencies. Many from major vendors like datadog, slack, twilio, nx (in the gcs-cache extension), etc...

Yep, got stung because a bunch of things still pull in axios even though we don't use it.

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

#795

"Batteries included" ecosystems are the only persistent solution to the package manager problem. If your first party tooling contains all the functionality you typically need, it's possible you can be productive with zero 3rd party dependencies. In practice you will tend to have a few, but you won't be vendoring out critical things like HTTP, TCP, JSON, string sanitation, cryptography. These are beacons for attackers…

While it's true that the packages are first party, .NET still relies on packages to distribute code that's not directly inside the framework. You still probably transiently depend on `Microsoft.Extensions.Hosting.Abstractions ` for example - if the process for publishing this package was compromised, you'd still get owned.

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

#797
post #687
post #674

Earlier quoted context omitted.

There are several issues with "Batteries Included" ecosystems (like Python, C#/.NET, and Java): 1. They are not going to include everything. This includes things like new file formats. 2. They are going to be out of date whenever a standard changes (HTML, etc.), application changes (e.g. SQLite/PostgreSQL/etc. for SQL/ORM bindings), or API changes (DirectX, Vulcan, etc.). 3. Things like data structures, graphics APIs…

"Batteries included" means "ossification is guaranteed", yah. "stdlib is where code goes to die" is a fairly common phrase for a reason. There's clearly merit to both sides, but personally I think a major underlying cause is that libraries are trusted . Obviously that doesn't match reality. We desperately need a permission system for libraries, it's far harder to sneak stuff in when doing so requires an "adds dangero…

Golang seems to do a good job of keeping the standard library up to date and clean

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

#798
post #657

Earlier quoted context omitted.

Vendoring means you don't have to fetch the internet for every build, that you can work offline, that you're not at the mercy of the oh-so-close-99.999 availability, that it will keep on working in 10 years, and probably other advantages. If your tooling can pull a dependency from the internet, it could certainly check if more recent version from a vendored one is available.

This is only true if you aren’t internally mirroring those packages. Most places I’ve worked have Artifactory or something like it sitting between you and actual PyPI/npm/etc. As long as someone has pulled that version at some point before the internet goes out, it’ll continue to work after.

And this is exactly why we see noise on HN/Reddit when a supply-chain cyberattack breaks out, but no breach is ever reported. Enterprises are protected by internal mirroring.

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

#799

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…

Is there a way to do that per repo for these tools ? We all know how user sided configuration works for users (they usually clean it whenever it goes against what they want to do instead of wondering why it blocks their changes :))

Fairly sure every single one has a repo level config that you can add these settings to. Others have pointed out the pnpm and npm, and I bunfig can also be repo level.
Post reply on HN