Live data from Hacker News

Axios compromised on NPM – Malicious versions drop remote access trojan

stepsecurity.io

531–540 of 894 posts

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

#531

Setting min-release age to 7 days is great, but the only true way to protect from supply chain attacks is restricting network access. This needs to be done (as we've seen from these recent attacks) in your devenv, ci/cd and prod environments. Not one, or two, but all of these environments. The easiest way is via using something like kubernetes network policies + a squid proxy to allow limited trusted domains through,…

> but raw.githubusercontent.com would be as it doesn't allow data to be submitted to it

But raw.githubusercontent.com still contains code and now the attacker can publish the code he wants no!?

Don't get me wrong: I love the idea to secure as much as possible. I'm running VMs and containerizing and I eat firewalling rules for breakfast, my own unbound DNS with hundreds of thousands (if not millions) of domains blocked, etc. I'm not the "YOLO" kind of guy.

But I don't understand what's that different between raw.githubusercontent.com and github.com? Is it for exploits that are not directly in the source code? Can you explain a bit more?

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

#532

"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…

So, youre on Microsoft then, judging by ScottPlot you write .NET desktop apps. If you use Dapper, you probably use Microsoft.Data.SqlClient, which is... distributed over NuGet and vulnerable to supply chain attack. You may not need many deps as a desktop dev. Modern day line of business apps require a lot more deps. CSVHelper, ClosedXML, AutoMapper, WebOptimizer, NetEscapades.AspNetCore.SecurityHeaders.

Yes less deps people need the better but it doesn't fix trhe core problem. Sharing and distrib uting code is a key tenant of being able to write modern code.

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

#533

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 majori…

Then you've got ecosystems like Clojure where many projects are just considered done and used by many. You can pin these (and be warned if a new version still comes out, say for an actual security fix). There are Clojure projects so stable, without any know exploit (we're certainly not talking about daily npm exploits here), that haven't been updated in years because they are... Done. Simply done. Perfection.

Something to reflect upon too.

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

#534
post #510
post #16

Earlier quoted context omitted.

> nearly every other project uses it for some reason instead of fetch (I never understood why). Fetch wasn't added to Node.js as a core package until version 18, and wasn't considered stable until version 21. Axios has been around much longer and was made part of popular frameworks and tutorials, which helps continue to propagate it's usage.

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.

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

#535

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…

[dead]

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

#537
post #415

Earlier quoted context omitted.

For a lot of code, I switched to generating code rather than using 3rd party libraries. Things like PEG parsers, path finding algorithms, string sanitizers, data type conversion, etc are very conveniently generated by LLMs. It's fast, reduces dependencies, and feels safer to me.

Or find the best third party library and copy the code from a widely used version that has been out long enough to have been well tested into your source tree. The problem is not third party libraries. It is updating third party libraries when the version you have still works fine for your needs.

Don't do this. Use a package manager that let's you specify a specific version to pin against. Vendoring side steps most automated tooling that can warn you about vulnerabilities. Vendoring is a signal that your tooling is insufficient, 99% of the time.

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

#538

[flagged]

This is a bot account posting LLM comments minutes apart. I have not investigated the shell script but DO NOT RUN shell scripts posted to Hacker News, especially by bot accounts!

[flagged]

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

#539

"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…

I agree that dependencies are a liability, but, sadly, "batteries included" didn't work out for Python in practice (i. e. how do I even live without numpy? No, array aren't enough).

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

#540
post #176

Earlier quoted context omitted.

At that point, you're making all your configuration fields strings and adding another parsing step after the json/toml/yaml parser is done with it. That's not ideal either; either you write a bunch of parsing code (not terribly difficult but not something I wanna do when I can just not), or you use some time library to parse a duration string, in which case the programming language and time library you happen to use…

TOML has a datetime type (both with or without tz), as well as plain date and plain time: start_at = 2026-05-27T07:32:00Z # RFC 3339 start_at = 2026-05-27 07:32:00Z # readable We should extend it with durations: timeout = PT15S # RFC 3339 And like for datetimes, we should have a readable variant: timeout = 15s # can omit "P" and "T" if not ambiguous, can use lowercase specifiers Edit: discussed in detail here: https:…

great, now attackers can also target all the libraries to enable all that complexity in npm too.
Post reply on HN