Summarizer

Transitive dependency risks

Concerns that even removing axios directly still pulls it as a transitive dependency from major vendors like Datadog, Slack, and Twilio

← Back to Axios compromised on NPM – Malicious versions drop remote access trojan

The persistence of Axios as a transitive dependency underscores a systemic fragility in the modern software ecosystem, where even diligent developers find it nearly impossible to purge vulnerable code buried within major vendor packages like Datadog or Slack. While some critics view the npm model as a "failed experiment" and a "house of cards," others contrast its fragmented nature with the "batteries-included" stability of .NET or the single-file simplicity of classic C libraries. This deep-rooted dependency bloat creates a digital "minefield," where the sheer scale of Axios’s 175,000 dependents ensures that supply chain attacks remain a ubiquitous threat regardless of whether a developer has migrated to native alternatives like `fetch`. Ultimately, the conversation reflects a growing sense of security nihilism, suggesting that no matter how much you pin versions or audit direct imports, you are likely still one sub-dependency away from being compromised.

28 comments tagged with this topic

View on HN · Topics
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...
View on HN · Topics
Yep, got stung because a bunch of things still pull in axios even though we don't use it.
View on HN · Topics
Fully agree with this! I think today .NET is probably the most batteries included platform you can get. This means that even if you use third-party libraries, these typically depend only on first-party dependencies, making it much less likely for something shady to sneak in.
View on HN · Topics
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.
View on HN · Topics
Don't be silly, this is the JS ecosystem. Why use your brain for a minute and come up with a 50 byte helper function, if you can instead import a library with 3912726 dependencies and let the compiler spend 90 seconds on every build to tree shake 3912723 out again and give you a highly optimized bundle that's only 3 megabytes small?
View on HN · Topics
> 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). You can remember this answer for every time you ask same question again: "Coz whatever else/builtin was before was annoying enough for common use cases"
View on HN · Topics
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.
View on HN · Topics
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).
View on HN · Topics
The prompt would be to approve the new malicious package (plain-crypto-js)'s scripts, too, which could tip users off that something was fishy. If they were used to approving one for axios and the attackers had just overwrote axios's own instead of making a new package, it would probably catch people out.
View on HN · Topics
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.
View on HN · Topics
It almost doesn't matter, because you can get pwned by a transitive dependency. If someone doesn't have the same scruples as you have, you're still at risk.
View on HN · Topics
minimumReleaseAge and lockfiles also pin down transitive dependencies.
View on HN · Topics
Package managers are a failed experiment. We have libraries like SQLite, which is a single .c file that you drag into your project and it immediately does a ton of incredibly useful, non-trivial work for you, while barely increasing your executable's size. The issue is not dependencies themselves, it's transitive ones. Nobody installs left-pad or is-even-number directly, and "libraries" like these are the vast majority of the attack surface. If you get rid of transitive dependencies, you get rid of the need of a package manager, as installing a package becomes unzipping a few files into a vendor/ folder. There's so many C libraries like this. Off the top of my head, SQLite, FreeType, OpenSSL, libcurl, libpng/jpeg, stb everything, zlib, lua, SDL, GLFW... I do game development so I'm most familiar with the ones commonly used in game engines, but I'm sure other fields have similarly high quality C libraries. They also bindings for every language under the sun. Rust libraries are very rarely used outside of Rust, and C#/Java/JS/Python libraries are never used outside their respective language (aside form Java ones in other JVM langs).
View on HN · Topics
Thought experiment: a language that enforces dependencies to be 2 levels deep or less. I wonder if dependencies would flatten out with this limitation in mind.
View on HN · Topics
The culture within the npm/js community has mainly been one of using the package manager rather than "re-inventing the wheel", as such the blast radius of a compromised package is much greater
View on HN · Topics
Rust is terrible for pulling in hundreds of dependencies though. Add tokio as a dependency and you'll get well over 100 packages added to your project.
View on HN · Topics
Even side stepping that tokio no longer pulls multiple packages, it used to be split into multiple packages, in the same way that KDE in Rust would be hundreds of packages. Rust projects tend to take their project and split it into many smaller packages, for ease of development, faster compiles through parallelization, ensuring proper splitting of concerns, and allowing code reuse by others. But the packages are equivalent to a single big package. The people that write it are the same. They get developed in tandem and published at the same time. You can take a look at the del tree for ripgrep, and the split of different parts of that app allows me to reuse the regex engine without dealing with APIs that only make sense in the context of a CLI app or pulling in code I won't ever use (which might be hiding an exploit too). Counting 100 100 line long crates all by the same authors as inherently more dangerous than 1 10000 line long crate makes no sense to me.
View on HN · Topics
pin-project-lite is the only base dependency, which itself has no dependencies. If you enable the "full" feature, ie all optional doodads turned on (which you likely don't need), it's 17: bytes, cfg-if, errno, libc, mio, parking_lot+parking_lot_core+lock_api, pin-project-lite, proc_macro2+quote+syn+unicode-ident, scopeguard, signal-hook-registry, smallvec, and socket2. You let me know which ones you think are bloat that it should reimplement or bind to a C library about, and without the blatant fabrication this time.
View on HN · Topics
Most of axios' functionality has effectively been promoted to a language feature as `fetch`, but the problem is people don't bother to migrate. I've migrated our direct usage of it but it's still pulled in transitively in several parts of our codebase. Even left-pad is still getting 1.6 million weekly downloads.
View on HN · Topics
PSA from the Claude Code leaks it looks like it's using Axios (although an older version)
View on HN · Topics
Axios has a long history, and is included in a lot of code, also in indirect dependencies. Just check its npm page: it has 174025 dependents as of this moment, including a lot of new packages (I see openclaw and mcp related packages in the list). And with LLMs generating more and more code, the risk of copying old setups increases.
View on HN · Topics
All these supply chain attacks make me nervous about the apps I use. It would be valuable info if an app used such dependencies, but on the other hand, programmers would cut their sales if they gave you this info.
View on HN · Topics
174025 dependents.
View on HN · Topics
The NPM ecosystem is a joke. I don't even want anything to do with it, because my stack is fully Elixir. But, just because of this one dependency that is used in some interfaces within my codebase, I need to go back to all my apps and fix it. Sigh. JavaScript, its entire ecosystem is just a pack of cards, I swear. What a fucking joke.
View on HN · Topics
My first thought was does VS Code Insiders use it (or anything it relies on, or do any extensions etc). Made me think.
View on HN · Topics
1/5 of your CLI and 1/3 of your gui apps are npm based. Each one has 400+ dependencies , none notable enough to go viral when they are breached. And who knows what other packages are currently compromised. We all have 30+ node_modules on our disks, and 2/3 of them were shipped by outside vendors , packaged in an archive. “I’m smart I use fetch instead of axios”. “I pin my versions” – sure but certainly one of your npx or Electron apps uses axios or another less notably compromised package. Let’s
View on HN · Topics
slowly walking through a minefield isn’t any safer than running. So unless you’re saying the extra time will be spent inspecting every package, whenever you do update, you will be getting an insecure package. You’re not safe by dodging axios. There are currently thousands of breached packages ready to install that aren’t notable. “I’ll run npm install after checking twitter” won’t help
View on HN · Topics
yet another npm supply chain attack, these are becoming as ubiquitous as gun violence in the US. We have become numb to it. One of my tools, bruno, was impacted but seems to be limited to cli via npm install [1] [1] https://github.com/usebruno/bruno/security/advisories/GHSA-6...