17 ms·
Axios compromised on NPM – Malicious versions drop remote access trojan
- twodave 6mo agoCan we get a non-AI-generated article for this? I think the aikido one might be fine, but if there’s a more official source let’s use that in lieu of this AI nonsense.
- mtud 6mo agoSupply chain woes continue
- kdavis01 6mo agoOne more reason to use Fetch
- marjipan200 6mo agountil Node is compromised
- avaer 6mo agoHarder to do. Also node is not updated at the rate of npm deps.
- p1mrx 6mo agoStop trying to make Fetch happen.
- nathanmills 6mo agoNo, I will not stop trying to create a more standardized and secure software ecosystem.
- peddling-brink 6mo agoThe comment you replied to is a quote from the movie Mean Girls. https://knowyourmeme.com/memes/stop-trying-to-make-fetch-happen https://knowyourmeme.com/memes/stop-trying-to-make-fetch-hap...
- nathanmills 6mo agoThats a coincidence
- moi2388 6mo agoIt’s a quote from the movie mean girls ;)
- deleted 6mo ago[deleted]
- johanyc 6mo agoLMAO take my upvote
- brovonov 6mo agois there even a reason to use axios?
- rvz 6mo agoCalled it yesterday.
- slopinthebag 6mo agoIt's reasons like this why I refuse to download Node or use anything NPM. Thankfully other languages are better anyways.
- wetpaws 6mo ago[dead]
- waterTanuki 6mo agoBecause no other language has ever had supply chain attacks ever, in history. Nope. https://blog.rust-lang.org/2022/05/10/malicious-crate-rustdecimal/ https://blog.rust-lang.org/2022/05/10/malicious-crate-rustde... https://en.wikipedia.org/wiki/Log4Shell https://en.wikipedia.org/wiki/Log4Shell https://blog.pypi.org/posts/2024-12-11-ultralytics-attack-analysis/ https://blog.pypi.org/posts/2024-12-11-ultralytics-attack-an... https://about.gitlab.com/blog/gitlab-catches-mongodb-go-module-supply-chain-attack/ https://about.gitlab.com/blog/gitlab-catches-mongodb-go-modu... https://www.reversinglabs.com/blog/packagist-php-repo-supply-chain-threat-what-you-need-to-know https://www.reversinglabs.com/blog/packagist-php-repo-supply...
- mememememememo 6mo agoC++ ftw
- skydhash 6mo agoOther languages have package managers (perl) and there are package managers in existence that are not so vulnerable to this issue. IMO, it stems from one place: Transitive dependencies and general opaqueness of the issue. In package managers like pacman, apt, apk,... it's easier to catch such issue. They do have postinstall scripts, but it's part of the submission to the repo, not part of the project. Whatever comes from the project is hashed, and that hash is also visible as part of the submission. That makes it a bit difficult to sneak something. You don't push a change, they pull yours.
- pianoben 6mo agoLog4Shell was hardly a supply-chain attack - just a latent bug in a widely-used library. That can happen anywhere. Maven to this day represents my ideal of package distribution. Immutable versions save so much trouble and I really don't understand why, in the age of left-pad, other people looked at that and said, "nah, I'm good with this."
- riteshkew1001 6mo ago[flagged]
- saadn92 6mo ago[dead]
- koolba 6mo ago> Both versions were published using the compromised npm credentials of a lead axios maintainer, bypassing the project's normal GitHub Actions CI/CD pipeline. Doesn’t npm mandate 2FA as of some time last year? How was that bypassed?
- bakugo 6mo agoApparently it's possible to create access tokens that bypass 2FA. Might've been this. https://docs.npmjs.com/creating-and-viewing-access-tokens https://docs.npmjs.com/creating-and-viewing-access-tokens
- stingraycharles 6mo agoCorrect, for CI/CD systems that want to push releases.
- masklinn 6mo agoIf GitHub, gitlab, or circleci, trusted publishing is available. No access token whatsoever.
- marjipan200 6mo agoIncident tracking: https://github.com/axios/axios/issues/10604 https://github.com/axios/axios/issues/10604
- 8cvor6j844qw_d6 6mo agoShould increase the delay to dependency updates.
- tonymet 6mo agoSlow Russian roulette is still a losing strategy
- btown 6mo agoIt’s only a losing strategy if you assume everyone universally adopts the slow strategy, and no research teams spot it in the interim. For things with large splash radius, that’s unrealistic, so defenders have an information advantage. Makes actual security patches tougher to roll out though - you need to be vigilant to bypass the slowdown when you’re actually fixing a critical flaw. But nobody said this would be easy!
- esseph 6mo ago> Makes actual security patches tougher to roll out though Yeah. 7 days in 2026 is a LONG TIME for security patches, especially for anything public facing. Stuck between a rock (dependency compromise) and a hard place (legitimate security vulnerabilities). Doesn't seem like a viable long-term solution.
- neko_ranger 6mo agobut wouldn't it work in this case? sure if a package was compromised for months/years it wouldn't save you but tell dependabot to delay a week, you'd sleep easy from this nonesense
- tonymet 6mo agoslowly 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
- jadar 6mo agoHow much do you want to bet me that the credential was stolen during the previous LiteLLM incident? At what point are we going to have to stop using these package managers because it's not secure? I've got to admit, it's got me nervous to use Python or Node.js these days, but it's really a universal problem.
- rybosome 6mo ago> it’s got me nervous to use Python or Node.js these days My feelings precisely. Min package age (supported in uv and all JS package managers) is nice but I still feel extremely hesitant to upgrade my deps or start a new project at the moment. I don’t think this is going to stabilize any time soon, so figuring out how to handle potentially compromised deps is something we will all need to think about.
- Tazerenix 6mo agoNPM only gained minimum package age in February of this year, and still doesn't support package exclusions for internal packages. https://github.com/npm/cli/pull/8965 https://github.com/npm/cli/pull/8965 https://github.com/npm/cli/issues/8994 https://github.com/npm/cli/issues/8994 Its good that that they finally got there but.... I would be avoiding npm itself on principle in the JS ecosystem. Use a package manager that has a history of actually caring about these issues in a timely manner.
- arcfour 6mo ago
- h4ch1 6mo agoI 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). Also from the report: > Neither malicious version contains a single line of malicious code inside axios itself. Instead, both inject a fake dependency, plain-crypto-js@4.2.1, a package that is never imported anywhere in the axios source, whose only purpose is to run a postinstall script that deploys a cross-platform remote access trojan (RAT) Good news for pnpm/bun users who have to manually approve postinstall scripts.
- beart 6mo ago> 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.
- seer 6mo agoAlso 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.
- reactordev 6mo agoYou can do all of that in fetch really easily with the init object. fetch('https://api.example.com/data', { headers: { 'Authorization': 'Bearer ' + accessToken } })
- mhio 6mo agoWhat does an interceptor in the RequestInit look like?
- 6mo ago
- tonymet 6mo agoHas anyone tested general purpose malware detection on supply chains ? Like clamscan . I tried to test the LiteLLM hack but the affected packages had been pulled. Windows Defender AV has an inference based detector that may work when signatures have not yet been published
- esseph 6mo ago> Has anyone tested general purpose malware detection on supply chains ? Like clamscan You could use Trivy! /s
- jesse_dot_id 6mo agoI second this question. I usually scan our containers with snyk and guarddog, and have wondered about guarddog in particular because it adds so much build time.
- Imustaskforhelp 6mo ago> tried to test the LiteLLM hack but the affected packages had been pulled Hey, I have been part of the archival effect/Litellm issue thread. I think I have stored them in archive.org for preservation purposes https://web.archive.org/web/20260325073027/https://files.pythonhosted.org/packages/f6/2c/731b614e6cee0bca1e010a36fd381fba69ee836fe3cb6753ba23ef2b9601/litellm-1.82.8.tar.gz https://web.archive.org/web/20260325073027/https://files.pyt... (I have also made an archive of the github issue with all the comments manually till a certain point at https://web.archive.org/web/20260325054202/https://serjaimelannister.github.io/litellm-comments/ https://web.archive.org/web/20260325054202/https://serjaimel...)
- tonymet 6mo agothanks for highlighting that i will take a look and see if there's similar archive for the other vulnerabilities as well . If i can make it work with clamscan & MS Defender i'll run a scan and try to report back
- Imustaskforhelp 6mo ago
- postalcoder 6mo agoPSA: 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-scripts=true ~/Library/Preferences/pnpm/rc minimum-release-age=10080 # minutes ~/.bunfig.toml [install] minimumReleaseAge = 604800 # seconds (Side note, it's wild that npm, bun, and pnpm have all decided to use different time units for this configuration.) If you're developing with LLM agents, you should also update your AGENTS.md/CLAUDE.md file with some guidance on how to handle failures stemming from this config as they will cause the agent to unproductively spin its wheels.
- mhio 6mo agoand for yarn berry ~/.yarnrc.yml npmMinimalAgeGate: "3d"
- XYen0n 6mo agoIf everyone avoids using packages released within the last 7 days, malicious code is more likely to remain dormant for 7 days.
- DimmieMan 6mo agoThey’re usually picked up by scanners by then.
- cozzyd 6mo agothat's why people are telling others to use 7 days but using 8 days themselves :)
- porridgeraisin 6mo agoGenius
- wongarsu 6mo ago
- 0x500x79 6mo agoPin your dependencies folks! Audit and don't upgrade to every brand new version.
- onion2k 6mo agoBut also have a regular review of your dependencies to update them when necessary, because as bad as compromised packages may be things do have vulnerabilities occasionally, and upgrading things that are a long way out-of-date can be quite hard.
- deleted 6mo ago[deleted]
- himata4113 6mo agoI recommend everyone to use bwrap if you're on linux and alias all package managers / anything that has post build logic with it. I have bwrap configured to override: npm, pip, cargo, mvn, gradle, everything you can think of and I only give it the access it needs, strip anything that is useless to it anyway, deny dbus, sockets, everything. SSH is forwarded via socket (ssh-add). This limits the blast radius to your CWD and package manager caches and often won't even work since the malware usually expects some things to be available which are not in a permissionless sandbox. You can think of it as running a docker container, but without the requirement of having to have an image. It is the same thing flatpak is based on. As for server deployments, container hardening is your friend. Most supply chain attacks target build scripts so as long as you treat your CI/CD as an untrusted environment you should be good - there's quite a few resources on this so won't go into detail. Bonus points: use the same sandbox for AI. Stay safe out there.
- vips7L 6mo agoAFAIK maven doesn’t support post install logic like npm does. You have to explicitly optin with build plugins. It doesn’t let any arbitrary dependency run code on your machine.
- himata4113 6mo agosome post processors have chains to execution (ex: lombok)
- vips7L 6mo agoYou explicitly opt in by using a compiler plugin. Merely having it as a dependency, like in npm, doesn’t mean it can run code at build time.
- johntash 6mo agoDo you have a recommendation for something like bwrap but for macos? I've been trying to use bwrap more on my servers when I remember.
- imrozim 6mo ago[flagged]
- joshuat 6mo agoWhy would pinning the exact version in this case not have solved the problem? I agree `--ignore-scripts` would be a sensible default at this point, but my understanding is that this vulnerability exclusively impacts two newly released versions.
- jmward01 6mo agoThis may not be popular, but is there a place for required human actions or just timed actions to slow down things like this? For instance, maybe a GH action to deploy requires a final human click and to change that to cli has a 3 day cooling period with mandatory security emails sent out. Similarly, you switch to read only for 6 hrs after an email change. There are holes in these ideas but the basic concept is to treat security more like physical security, your goal isn't always to 100% block but instead to slow an attacker for xxx minutes to give the rest of the team time to figure out what is going on.
- ArcHound 6mo agoHi, security here. We've tried, but the amount of people you need for this vs the amount of people you have trying to review and click the big button always means that this step will be a bottleneck. Thus this step will be eliminated. A much better approach would be to pin the versions used and do intentional updates some time after release, say a sprint after.
- jmward01 6mo agoYeah, I am looking at that on the use end. It sounds like on the python side this type of thing will be more standard (uv now and soon pip supported with version date requirements). I think time is a big missing element in many security in depth decisions. It can be time until you adopt like use no package newer than xx days or time it takes to deploy etc etc. Unfortunately the ecosystem is getting really diverse and that means ever more sophisticated attacks so we may need to do things that are annoying just to survive.
- ArcHound 6mo agoYes, that's why I recommend intentional updates. Planning at least a sprint later gives you a week or two, hoping the community catches such issues.
- themafia 6mo agoWhy not just release escrow? If I try to push a new release version another developer or developers have to agree to that release. In larger projects you would expect the release to be coordinated or scheduled anyways. Effectively we're just moving "version pinning" or "version delay" one layer up the release chain.
- bluepeter 6mo agoMin release age sucks, but we’ve been here before. Email attachments used to just run wild too, then everyone added quarantine delays and file blocking and other frictions... and it eventually kinda/sorta worked. This does feel worse, though, with fewer chokepoints and execution as a natural part of the expectation. Edit: bottom line is installs are gonna get SOOO much more complicated. You can already see the solution surface... Cooling periods, maintainer profiling, sandbox detonation, lockfile diffing, weird publish path checks. All adds up to one giant PITA for fast easy dev.
- mayama 6mo agoMin release age might just postpone vulnerability to be applied few days later in non trivial cases like this. More I think about it, Odin lang approach of no package manager makes senses. But, for that approach won't work for Javascript as it needs npm package even for trivial things. Even vendoring approach like golang won't work with Javascript with the amount of churn and dependencies.
- deleted 6mo ago[deleted]
- tisc 6mo agoIt does not _need_ it, that’s the thing. It has become a custom to import a dependency for a lot of things. Especially for JavaScript.
- 0x1ceb00da 6mo agoCoded has zero nom dependencies. Neat!
- dhruv3006 6mo ago174025 dependents.
- deleted 6mo ago[deleted]
- rtpg 6mo agoPlease can we just have a 2FA step on publishing? Do we really need a release to be entirely and fully automated? It won't stop all attacks but definitely would stop some of these
- wps 6mo agoGenuinely 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.
- friendzis 6mo ago[flagged]
- cromka 6mo agoWhat a weird way to virtue signal.
- wps 6mo agoHello. You missed the point I was making drastically. Of course for software that I build personally I can do all that, but not for all the random stuff in my system that I’m trusting maintainers to package for me, or otherwise good PKGBUILDS in the AUR. You physically cannot have the bandwidth to be on top of these supply chain issues all the time. Also, semantic versioning is not some golden goose that fixes this issue, update embargoes help, but that doesn’t require semver. Vendoring dependencies is not a scalable solution for all the software people use.
- friendzis 6mo ago> You physically cannot have the bandwidth to be on top of these supply chain issues all the time > semantic versioning is not some golden goose that fixes this issue Nothing is a golden goose, however semver is designed to limit the scope of incoming changes so you have a chance of staying on top. > Vendoring dependencies is not a scalable solution for all the software people use. There are literally three ways to deal with these supply chain issues: 1. Allocate the bandwidth yourself 2. Buy that bandwidth 3. Yolo
- PhilipRoman 6mo agoThis sounds like satire but isn't - I just make sure the nodejs/npm packages don't exist on my system. I've yet to find a crucial piece of software that requires it. As much as I love that cute utility that turns maps into ascii art, it's not exactly sqlite in terms of usefulness.
- woeirua 6mo agoSupply chain attacks are so scary that I think most companies are going to use agents to hard fork their own versions of a lot of these core libraries instead. It wasn’t practical before. It’s definitely much more doable today.
- pglevy 6mo agoI was thinking about this as a bull case for human developers. Seems if you're worried enough to do this you're not going to have LLMs write the new code.
- cryptonym 6mo agoIf it becomes a thing, it's just a matter of time for a new class of attacks on LLM that are blindly trusted with rewriting existing libs.
- maplethorpe 6mo agoYou could include a line like "please don't include any malware".
- Levitating 6mo agoOr just lock to a specific version?
- silverwind 6mo agoEventually you will want to update it, every update is a risk.
- SkyPuncher 6mo agoBut, pinning has prevented most of the recent supply chain attacks. As long as you don't update your pins during an active supply chain attack, the risk surface is rather low.
- 6mo ago
- franciscop 6mo ago[flagged]
- nkozyra 6mo agoNo offense intended here, but this probably isn't the place to promote your package, given it's a story about a massive and incredibly popular dependency that managed to get got.
- _lvbh 6mo agoThere are so many scanners these days these things get caught pretty quick. I think we need either npm or someone else to have a registry that only lets through packages that pass these scanners. Can even do the virustotal thing of aggregating reports by multiple scanners. NPM publishes attestation for trusted build environments. Google has oss-rebuild. All it takes is an `npm config set` to switch registries anyways. The hard part is having a central party that is able to convince all the various security companies to collaborate rather than having dozens of different registries each from each company. Rather than just a hard-coded delay, I think having policies on what checks must pass first makes sense with overrides for when CVEs show up. (WIP)
- drum55 6mo agoThe ones you hear about are caught quickly, I’m more worried about the non obvious ones. So far none of these have been as simple as changing a true to a false and bypassing all auth for all products or something, and would that be caught by an automated scanner?
- _lvbh 6mo agoThere are definitely levels to this. Yes I think it can be caught by automated scanners in theory. Either commit by commit scanning and reproducible builds or fuzzing and getting the behavioral differences between versions
- pamcake 6mo agoSounds great until trivy images get compromised, like last week.
- _lvbh 6mo agoHence why you source data from multiple vendors I'd say. Rather than putting all eggs in one basket
- vsgherzi 6mo agoNot 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.
- rectang 6mo agoHosting curated dependencies is a commercially valuable service. Eventually an economy arises where people pay vendors to vet packages.
- tankenmate 6mo agoIt already exists; cloudsmith
- goodpoint 6mo agoIt's what linux distributions do.
- anthk 6mo agoLinux distros and BSD ports did that since the 90's. When Linux distros had barely a PM or just tarballs, Infomagic sold 4 CD full of libre software. When I had no internet at home, back in the day I bought 3 DVD's of Debian Sarge for 20 euros, about $20. A bargain, it was the price of a hard-cover best seller book. GB's of libre software, graphical install, 2.6 kernel, KDE3 desktop, very light on my Athlon 2000 with 256MB of RAM. It was incredible compared to what you got with Windows XP and 120 Euro per seat. Nonfree software and almost empty. And, well, if for instance I could get read only, ~16TB durable USB drive with tons of Guix packages offline (in a two yearly basis with stable releases) for $200 I would buy them in the spot. You would say that $200 for a distro it's expensive, but for what it provides, if you are only interested in libre gaming and tools, they amount you save can be huge. I've seen people spend $400 in Steam games because of the Holyday sales...
- stevenmh 6mo agoThis is why Node.js is completely unsuitable as backend. Until recently, there wasn’t even a standard Promise-based HTTP client. Why should we need to download a library just to make a simple HTTP request? It’s because Node.js’s standard library is too limited, leading to an explosive growth in third-party libraries. As a result, it’s vulnerable to security attacks, and maintaining it in an enterprise environment becomes a major challenge. Let’s use .NET or Go. Why use JavaScript outside of the browser when there are excellent backend environments out there?
- Surac 6mo agoAll 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.
- tkel 6mo agoJS package managers (pnpm, bun) now will ignore postinstall scripts by default. Except for npm, it still runs them for legacy reasons. You should probably set your default to not run those scripts. They are mostly unnecessary. ~/.npmrc : ignore-scripts=true 83M weekly downloads!
- yoyohello13 6mo agoThis 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.
- leventhan 6mo agoPSA: Make sure to set a minimum release age and pin versions where possible.
- k4binSecurity 6mo ago[flagged]
- pjmlp 6mo agoThe amount of people still using this instead of fetch. Nonetheless when wasn't axios, it would be something else. This is why corporations doing it right don't allow installing the Internet into dev machines. Yet everyone gets to throw their joke about PC virus, while having learnt nothing from it.
- shevy-java 6mo ago> The amount of people still using this instead of fetch. People are lazy. And sometimes they find old stuff via a google search and use that.
- tgv 6mo agoAxios 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.
- nananana9 6mo agoPackage 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).
- hvb2 6mo agoIf you're developing for the web your attack surface is quite a bit bigger. Your proposed solution of copying a few files might work but how do you keep track of updates? You might be vulnerable to a published exploit fixed a few months ago. A package manager might tell you a new version is available. I don't know how that would work in your scenario.
- deleted 6mo ago[deleted]
- voidfunc 6mo agoI'd really like to see package managers organized around rings where a very small core of incredibly important stuff is kept in ring 0, ring 1 gets a slightly wider amount of stuff and can only depend on ring 0 dependencies and then ring 2+ is the crapware libraries that infect most ecosystems. But maybe that's not the right fit either. The world where package managers are just open to whatever needs to die. It's no longer a safe model.
- pasanhk 6mo ago[flagged]
- shevy-java 6mo agoNPM gets worse than russian roulette. Perhaps we have to rename russian roulette to node roulette: noulette.
- Kinrany 6mo agoRunning almost anything via npx will trigger this
- hyperadvanced 6mo agoJust sanity checking - if I only ever install axios in a container that has no secrets mounted in to its env, is there any real way I can get pwned by this kind of thing?
- monarchwadia 6mo agoYes. Docker breakout is a class of vulnerabilities into itself.
- strogonoff 6mo agoEssential steps to minimise your exposure to NPM supply chain attacks: — Run Yarn in zero-installs mode (or equivalent for your package manager). Every new or changed dependency gets checked in. — Disable post-install scripts. If you don’t, at least make sure your package manager prompts for scripts during install, in which case you stop and look at what it’s going to run. — If third-party code runs in development, including post-install scripts, try your best to make sure it happens in a VM/container. — Vet every package you add. Popularity is a plus, recent commit time is a minus: if you have this but not that, keep your eyes peeled. Skim through the code on NPM (they will probably never stop labelling it as “beta”), commit history and changelog. — Vet its dependency tree. Dependencies is a vector for attack on you and your users, and any new developer in the tree is another person you’re trusting to not be malicious and to take all of the above measures, too.
- wesammikhail 6mo ago[flagged]
- inbx0 6mo ago> Run Yarn in zero-installs mode (or equivalent for your package manager). Every new or changed dependency gets checked in. Idk, lockfiles provide almost as good protection without putting the binaries in git. At least with `--frozen-lockfile` option.
- littlecranky67 6mo agoExactly. Yarn uses a yarn.lock file with the sha256 hashes of each npm package it downloads from the repo (they are .tgz files). If the hash won't match, install fails. No need to commit the dependencies into your git.
- strogonoff 6mo agoZero-installs mode does not replace the lockfile. Your lockfile is still the source of truth regarding integrity hashes. However, it’s an extra line of defence against 1) your registry being down (preventing you from pushing a security hotfix when you find out another package compromised your product), 2) package unpublishing attacks (your install step fails or asks you to pick a replacement version, what do you do at 5pm on a Friday?), and 3) possibly (but haven’t looked in depth) lockfile poisoning attacks, by making them more complicated. Also, it makes the size of your dependency graph (or changes therein) much more tangible and obvious, compared to some lines in a lockfile.
- firekey_browser 6mo ago[dead]
- aizk 6mo agoIn light of these nonstop supply chain attacks: Tonight I created /supply-chain-audit -- A simple claude code skill that fetches info on the latest major package vulnerability, then scans your entire ~/ and gives you a report on all your projects. https://github.com/IsaacGemal/claude-skills https://github.com/IsaacGemal/claude-skills It's a bit janky right now but I'd be interested to hear what people think about it.
- mirekrusin 6mo agoSkills are great attack vector as well.
- mayhemducks 6mo agoThat sounds terrifying. Stay out of my ~/ thank you very much.
- ksk23 6mo agoOne paragraph is written two times??
- neya 6mo agoThe 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.
- OlivOnTech 6mo agoThe attacker went through the hassle to compromise a very widely used package, but use a non standard port (8000) on their C2... If you plan to do something like that, use 443 at least, many corporate network do not filter this one ;)
- neya 6mo agoI wonder if this has any connection with the recent string of attacks including the FBI director getting hacked. The attack surface is large, executed extremely cleanly - almost as if done by a high profile state sponsored actor, just like in Hollywood movies.
- raphinou 6mo agoI'm working on a multi signature solution that helps to detect unauthorized releases in the case of an account hijack. It is open source, self hostable, accountless and I am looking for feedback! Website: https://asfaload.com/ https://asfaload.com/ GitHub:https://github.com/asfaload/asfaload https://github.com/asfaload/asfaload Spec: https://github.com/asfaload/spec https://github.com/asfaload/spec
- aa-jv 6mo agoI have a few projects which rely on npm (and react) and every few months I have to revisit them to do an update and make sure they still build, and I am basically done with npm and the entire ecosystem at this point. Sure, its convenient to have so much code to use for basic functionality - but the technical debt of having to maintain these projects is just too damn high. At this point I think that, if I am forced to use javascript or node for a project, I reconsider involvement in that project. Its ecosystem is just so bonkers I can't justify the effort much longer. There has to be some kind of "code-review-as-a-service" that can be turned on here to catch these things. Its just so unproductive, every single time.
- wolvesechoes 6mo agoI am glad I don't need to touch JS or web dev at all. Now, I tend to use Python, Rust and Julia. With Python I am constantly using few same packages like numpy and matplotlib. With Rust and Julia, I try as much as possible to not use any packages at all, because it always scares me when something that should be pretty simple downloads half of the Internet to my PC. Julia is even worse than Rust in that regard - for even rudimentary stuff like static arrays or properly namespaced enums people download 3rd party packages.
- hu3 6mo agoIt's mind boggling when a simple Rust app pulls in Serde and with it half a black hole worth of packages to serialize some mundane JSON.
- someguyornotidk 6mo agoIsn't Rust just as susceptible to this issue? For example, how do you deal with Rust's lack of support for HTTP in the standard library? Importing hyper pulls in a couple dozen transitive libraries which exposes you to the exact same kind of threats that compromised axios. Given how HTTP is now what TCP was during the 90s and almost all modern networked applications needing to communicate in it one way or another, most rust projects come with an inherent security risk. These days, I score the usability of programming languages by how complete their standard library is. By that measure, Rust and Javascript get an automatic F.
- wolvesechoes 6mo agoIt is, therefore I have stated I avoid any dependencies while writing Rust, unless they are self-contained. And I said I am glad I don't do web, so I don't have need for HTTP implementations.
- lepuski 6mo agoI believe compartmentalized operating systems like Qubes are the future for defending against these kinds of attacks. Storing your sensitive data on a single bare-metal OS that constantly downloads and runs packages from unknown maintainers is like handing your house key out to a million people and hoping none of them misuse it.
- lukewarm707 6mo agoi am rolling back a huge number of 'features' in my personal pc and going back to extremely miminal setups the security solution i have is where it needs to become more simple, getting rid of attack surface that is coming out of these bloated releases
- mcintyre1994 6mo agoThe frustrating thing here is that axios versions display on npmjs with verified provenance. But they don’t use trusted publishing: https://github.com/axios/axios/issues/7055 https://github.com/axios/axios/issues/7055 - meaning the publish token can be stolen. I wrongly thought that the verified provenance UI showed a package has a trusted publishing pipeline, but seems it’s orthogonal. NPM really needs to move away from these secrets that can be stolen.
- Hackbraten 6mo agoI am now migrating all my unencrypted secrets on my machines to encrypted ones. If a tool supports scripted credential providers (e.g. aws-cli or Ansible), I use that feature. Otherwise, I wrap the executable with a script that runs gpg --decrypt and injects an environment variable. That way, I can at least limit the blast radius when (not if) I catch an infostealer.
- zar1048576 6mo agoIn case it helps, we open-sourced a tool to audit dependencies for this kind of supply-chain issue. The motivation was that there is a real gap between classic “known vulnerability” scanning and packages whose behavior has simply turned suspicious or malicious. We also use AI to analyze code and dependency changes for more novel or generic malicious behavior that traditional scanners often miss. Project: https://point-wild.github.io/who-touched-my-packages/ https://point-wild.github.io/who-touched-my-packages/
- charcircuit 6mo agoHopefully desktop Linux users will start to understand that malware actually does exist for Linux and that their operating system is doing nothing to protect them from getting RATed.
- hu3 6mo agoWhat do you mean? Linux has the most powerful native process isolation arsenal at the user disposal. And some distros use even more isolation mechanisms on top of the ones provided by the kernel like snap and flatpak. And then you can recreate the entire thing like a spellbook with nix. Docker works natively in it. Do I need to say more? Linux is a decade ahead here with regards for security options available to the user.
- charcircuit 6mo agoYet npm isn't using them allowing this RAT to work. It is not secure by default. It requires every app to manually opt in to being secure. This opt in approach to security puts desktop Linux decades behind in regards to security. Not ahead.
- hu3 6mo agoLinux is not making anything less secure than other OSs. In fact it even gives the user more security tools. So I fail to reason on you singling out Linux here.
- charcircuit 6mo agoTake for example iOS and Android. All apps are sandboxed by default. You can't make a program that just steals all of your credentials like you can on desktop Linux. Having security tools means nothing if they aren't being used.
- hu3 6mo agoNo one is running npm in Android or iOS. A more apt comparison is vs Windows and macOS. And Linux offer more than these two with regards to security.
- sgt 6mo agoIs this an issue for those only using axios on the frontend side like in a VueJS app?
- dfreire 6mo agoAbsolutely. If you ever did a npm install on a project using one of the affected axios versions, your entire system may be compromised. > The malicious versions inject a new dependency, plain-crypto-js@4.2.1, which is never imported anywhere in the axios source code. Its sole purpose is to execute a postinstall script that acts as a cross platform remote access trojan (RAT) dropper, targeting macOS, Windows, and Linux. The dropper contacts a live command and control server and delivers platform specific second stage payloads. After execution, the malware deletes itself and replaces its own package.json with a clean version to evade forensic detection. I strongly recommend you read the entire article.
- majorbugger 6mo agoGood morning, or as they say in the NPM world, which package got compromised today?
- lucasay 6mo ago[dead]
- wei03288 6mo ago[dead]
- getverdict 6mo ago[dead]
- croemer 6mo agoI lost respect for Axios when they made a breaking change in a patch release. Digging into the root cause, I found the maintainer had approved an outside PR with an obvious AI slop PR description: https://github.com/axios/axios/issues/7059 https://github.com/axios/axios/issues/7059 Looks like the maintainer wasn't just careless when reviewing PRs.
- fluxist 6mo agoA command to recursively check for the compromised axios package version: find / -path '*/node_modules/axios/package.json' -type f 2>/dev/null | while read -l f; set -l v (grep -oP '"version"\s*:\s\*"\K(1\.14\.1|0\.30\.4)' $f 2>/dev/null); if test -n "$v"; printf '\a\n\033[1;31m FOUND v%s\033[0m \033[1;33m%s\033[0m\n' $v (string replace '/package.json' '' -- $f); else; printf '\r\033[2m scanning: %s\033[K\033[0m' (string sub -l 70 -- $f); end; end; printf '\r\033[K\n\033[1;32m scan complete\033[0m\n'
- hk__2 6mo agoOr more simply: find / -type f -path '*/node_modules/axios/package.json' \ -exec grep -Pl '"version"\s*:\s*"(1\.14\.1|0\.30\.4)"' {} + 2>/dev/null Let’s not encourage people to respond to security incidents by… copy/pasting random commands they don’t understand.
- deleted 6mo ago[deleted]
- skydhash 6mo agoWhat’s with all those escapes codes?
- sph 6mo agoscript kiddies love their ANSI color codes and fancy ASCII art
- jruohonen 6mo agoSo the root cause was again a developer's opsec. For improving things, I haven't seen many new initiatives on that side (beyond 2FA, but even that seems unenforced in these repositories, I reckon).
- cleansy 6mo agoTo have an initial smoke test, why not run a diff between version upgrades, and potentially let an llm summarise the changes? It’s a baffling practice that a lot of developers are just blindly trusting code repos to keep the security standards. Last time I installed some npm package (in a container) it loaded 521 dependencies and my heart rate jumped a bit
- dj_mc_merlin 6mo agoIs this the first time you have ever thought about the idea of supply chain attacks? This is the first thought 90% of people have and it doesn't work. Too much work to manually verify diffs and LLMs aren't good enough at this yet.
- tomjwxf 6mo ago[dead]
- dinakernel 6mo agoDefault setting latest should be caught in every static code scanner. How many times has this issue been raised.
- silverwind 6mo agonpm really needs to provide a options to set individual packages to only be publishable via trusted publishing.
- maelito 6mo agoGlad to be using native fetch.
- bob1029 6mo ago"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. Everything depends on this stuff so the motivation for attacking these common surfaces is high. I can literally count on one hand the number of 3rd party dependencies I've used in the last year. Dapper is the only regular thing I can come up with. Sometimes ScottPlot. Both of my SQL providers (MSSQL and SQLite) are first party as well. This is a major reason why they're the only sql providers I use. Maybe I am just so traumatized from compliance and auditing in regulated software business, but this feels like a happier way to build software too. My tools tend to stay right where I left them the previous day. I don't have to worry about my hammer or screw drivers stealing all my bitcoin in the middle of the night.
- junon 6mo agoThis is a rather superlative and tunnel vision, "everything is a nail because I'm a hammer" approach. The truth is this is an exceedingly difficult problem nobody has adequately solved yet.
- bbkane 6mo agoI think the AI tooling is, if not completely solving sandboxing, at least making the default much better by asking you every time they want to do something and providing files to auto-approve certain actions. Package managers should do the same thing
- hectdev 6mo agoAnother layer of AI tooling is the cost of spinning up your own version of some libraries is lowered and can be made hyper specific to your needs rather than pulling in a whole library with features you'll never use.
- webprofusion 6mo agoMy first thought was does VS Code Insiders use it (or anything it relies on, or do any extensions etc). Made me think.
- Imustaskforhelp 6mo agoIf someone from github is reading this, https://github.com/axios/axios/issues/10604#issuecomment-4160960760 https://github.com/axios/axios/issues/10604#issuecomment-416... I think that jason might like if someone from github team can contact them as soon as possible. (8 minutes ago at the time of writing)
- est 6mo agocompiled JS solves a problem that no longer exists. IE6 is dead RIP. Now we have a 20MB main.min.js problem
- bodash 6mo agoSome great tips in this thread and I've been collecting them all at https://github.com/bodadotsh/npm-security-best-practices https://github.com/bodadotsh/npm-security-best-practices
- Ciantic 6mo agoNPM should learn from Linux distribution package managers. Have a branch called testing, and packages stay in testing for few weeks, after which they go to stable. That is how many Linux distributions handle packages. It would have prevented many of these. Advising every user of npm/pnpm to change their settings and set their own cooldown periods is not a real choice.
- ivanjermakov 6mo agoNPM is one big AUR, where anyone can submit arbitrary unverified code. The difference is that AUR is intentionally harder to use to prevent catastrophic one-line installs.
- Levitating 6mo agoIs a "AUR" now just how we name unaudited software repositories? Just to note, if we're talking about Linux Distributions. There's also COPR in Fedora, OBS for OpenSUSE (and a bunch of other stuff, OBS is awesome), Ubuntu has PPAs. And I am sure there's many more similar solutions.
- Levitating 6mo agoNot all distributions work with a staging repository, and it's not really intended for this purpose either. Besides there's always a way to immediately push a new version to stable repositories. You have to in order to deal with regressions and security fixes.
- Ciantic 6mo agoI know not all, but Debian/Ubuntu/Fedora does, and while the intended purpose of multi-stage releases is not necessarily security but stability, it still does help up with security too. Because third parties can look and scan the dependencies while they are still not in stable. Most of the supply chain vulnerabilities that ended up in the NPM would have been mitigated with having mandatory testing / stable branches, of course there needs to be some sort of way to skip the testing but that would be rather rare and cumbersome and audited, like it is in Linux distributions too.
- red_admiral 6mo agoThere's a package manager discussion, but the bit that stands out to me is that this started with a credential compromise. At some point when a project gets big enough like axios, maybe the community could chip in to buy the authors a couple of YubiHSM or similar. I wish that _important keys live in hardware_ becomes more standard given the stakes. Dealing with dependencies is another question; if it's stupid stuff like leftpad then it should be either vendored in or promoted to be a language feature anyway (as it has been).
- pamcake 6mo agoOr those people can (fund) separate repackaging and redistribution with more stringent and formalized review process. Maybe not all users should pull all packages straight from what devs are pushing. There's no reason we can't have "node package distributions" like we have Linux distributions. Maybe we should stop expecting devs and maintainers and Microsoft to take responsibility for our supply-chain.
- filleokus 6mo agoTotally agree. Also, considering how prevalent TPM/Secure Enclaves are on modern devices, I would guess most package maintainers already have hardware capable of generating/using signing keys that never leave hardware. I think it is mostly a devex/workflow question. Considering the recent ci/cd-pipeline compromises, I think it would make sense to make a two phase commit process required for popular packages. Build and upload to the registry from a pipeline, but require a signature from a hardware resident key before making the package available.
- rjmunro 6mo agoMost 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.
- embedding-shape 6mo ago
- _pdp_ 6mo agoI am not saying this is the reason for this compromise but the sudden explosion of coding assistant like claude code, and tools like openclaw is teaching entire crop of developers (and users) that it is ok to have sensitive credentials .env files.
- TheTaytay 6mo agoI know there is a cooldown period for npm packages, but I’m beginning to want a cooldown for domains too. According to socket, the C2 server is sfrclak[.]com, which was registered in the last 24 hours.
- ArtinOr 6mo agoReset the clock
- SophieVeldman 6mo ago[flagged]
- kush3434 6mo agofirst day at hacker news and this is the first post i saw
- rk06 6mo ago> This creates a secondary deception layer. After infection, running npm list in the project directory will report plain-crypto-js@4.2.0 — because npm list reads the version field from the installed package.json, which now says 4.2.0. An incident responder checking installed packages would see a version number that does not match the malicious 4.2.1 version they were told to look for, potentially leading them to conclude the system was not compromised. WTF!!!! gaslighting your victims into believing they are not victims. the ingenuity of this is truly mindblowing. I am shocked at such thing is even allowed. like packages should not be able to modify their contents while they are being instaleld.
- croemer 6mo agoI'm impressed how this was caught as a network anomaly in a GitHub actions monitoring tool. This might have taken a lot longer to discover, otherwise.
- anthk 6mo agoGuix saves you from this. You can import NPM packages in a container (not even touching $HOME) and giving you a shell on the spot with just the dependencies and nothing more. Learn about 'guix import'. Oh, and you can install Guix on any GNU/Linux distro.
- diego_sandoval 6mo agoA new day, a new npm incident.
- JCharante 6mo agoI don't see how a system that relies on trust can scale safely
- george_max 6mo agoWith all the recent supply chain attacks, I'm starting to think it's only a matter of time before all of us are victims. I think this is a sign to manually check all package diffs or postinstall scripts.
- crimsonnoodle58 6mo agoSetting 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, and those domains must not be publicly controllable by attackers. ie. github.com is not safe to allow, but raw.githubusercontent.com would be as it doesn't allow data to be submitted to it. Network firewalls that perform SSL interception and restrict DNS queries are an option also, though more complicated or expensive than the above. This stops both DNS exfil and HTTP exfil. For your devenv, software like Little Snitch may protect your from these (I'm not 100% on DNS exfil here though). Otherwise run your devenv (ie vscode) as a web server, or containerised + vnc, a VM, etc, with the same restrictions.
- nicce 6mo ago> Setting min-release age to 7 days is great, but the only true way to protect from supply chain attacks is restricting network access. Getting zero day patches 7 days later if no proper monitoring about important patches or if this specific patch is not in the important list. Always a tradeoff.
- crimsonnoodle58 6mo agoThats true. Setting to 7 days saves you from a supply chain attack, but opens you to zero days. Another example why network filtering is a better solution.
- TacticalCoder 6mo ago> 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?
- samuelknight 6mo agoAbsolute wave of supply chain attacks recently. Hopefully this causes everyone to tighten up their dependencies and update policies.
- TZubiri 6mo agoI've been saying for ages, use xmlhttprequest, or hell, even fetch(). Stop downloading code from the internet unless it's a major strategic decision.
- deleted 6mo ago[deleted]
- jFriedensreich 6mo agoJust a reminder that you can run most node things with deno run and have opt in permissions, audit trail and even external permission system integration now. The gotcha is that "deno task <<some package.json script>>" will NOT execute with this model which I find extremely unintuitive and had me thinking deno abandoned its sandbox for nodejs compatibility completely.
- noritaka88 6mo ago[flagged]
- Aurornis 6mo agoThis 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!
- noritaka88 6mo ago[flagged]
- woodruffw 6mo agoThere’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 (Python and JS): packagers should use Trusted Publishing to eliminate the need for long lived release credentials, and downstreams should use cooldowns to give security researchers time to identify and quarantine attacks. (Security is a moving target, and neither of these techniques is going to work indefinitely without new techniques added to the mix. But they would be effective against the current problems we’re seeing.)
- MattDaEskimo 6mo agoThere are solutions, the problem is almost always discipline.
- woodruffw 6mo agoI don’t know what this means. Discipline is good, but I think you need to have good tools/primitives in place to help people exercise discipline. (The classic example being passwords: we wouldn’t need MFA is everybody just “got good” and used strong/unique passwords everywhere. But that’s manifestly unrealistic, so instead we use our discipline budget on getting people to use password managers and phishing-resistant MFA.)
- MattDaEskimo 6mo agoReally? You don't know the difference between having a door lock, and using it? MFA is typically enforced by organizations, forcing discipline. Individual usage of MFA is dramatically lower
- paustint 6mo agoIn 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 since the entire NPM account was taken over and config can be modified to allow publishing using a token.
- xinayder 6mo agoVery 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.
- nicce 6mo agoIt is harder and harder to trust any blog post anymore, the more AI there is. I used to read blog posts because of the personality and the precision level. Now both have been taken away.
- rc_mob 6mo agoYeah, 98% of blog posts only exist for SEO purposes and so most of that is of course written by LLM
- efilife 6mo agoIt 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
- darepublic 6mo agoI used axios in the distant past but haven't used it whenever I had my say in the past five years. You don't need it, and for special things like retries I could roll my own just fine. Now ai will roll it for you
- Kuyawa 6mo agonode:fetch is all you need, simple and effective
- malikolivier 6mo agoThis is exactly to avoid this kind of issue that I decided to work on StableBuild. StableBuild pins and hosts a copy of your dependencies at a specific freeze date, so that your supply chain is never contaminated. This way, a compromised version published after your freeze date (even with the same version number!) would never reach your build.
- habinero 6mo agoLiterally every package manager already does this.
- tmatsuzaki 6mo ago[dead]
- bustah 6mo ago[flagged]
- 1970-01-01 6mo agoIs this Jia Tan 5.0? I've lost count. You really should stop trusting packages (implicitly). Or don't. It's your funeral, not mine. See you at Jia Tan 6.0 April?
- __jonas 6mo agoNot at all, it was a regular maintainer account that was hijacked (probably through phishing) and used to push a malicious payload, not a threat actor posing as a contributor and adding a backdoor like in the Jia Tan case.
- 1970-01-01 6mo agoI use Jia Tan as a figurehead for malicious maintainers. This clearly was a targeted hack. Does it really matter how long it took to get the job done?
- __jonas 6mo agoI'd argue this has not much in common with Jia Tan apart from both being supply chain attacks, there is no malicious maintainer here, a trusted maintainer had their account taken over. I guess the end result is the same, a malicious package pushed by an account that was thought to be trusted, but I think the Jia Tan case is worth being looked at differently than just simple account takeover.
- 1970-01-01 6mo agoIt's just a longer backstory. All the same in the end. Hackers targeted a popular package. The lead maintainer was compromised. The pattern fits. There will be more of these.
- nfodor 6mo ago[flagged]
- croemer 6mo agoYou mean you vibe coded something. "Zero deps. One file." People prefer hand-written comments over LLM-written ones. "Already detects the hijacked maintainer email on the current safe version." You simply flag all proton email addresses.
- 6thbit 6mo ago> published manually via a stolen npm access token with no OIDC binding and no gitHead So this and litellm one would’ve been preventable by proper config of OIDC Trusted Publishers.
- 6thbit 6mo agoI don’t buy the “wait 7 days” being thrown around as a guard. Wouldn’t that just encourage the bad actors to delay the activation of their payloads a few days or even remotely activated on a switch?
- roflcopter69 6mo agoOf course the "wait 7 days" are not a silver bullet, but it gives automated scanners plenty of time to do their work. Those automated scanners surely catch this `eval(base64.decode("..."))` stuff that some of those attacks used so in my book this dependency cooldown is a net win. I guess the skilled malicious actors will then up their game but I think it's okay to kick off an arms race between them and the security scanners in the dependency world.
- 6thbit 6mo agoThat's a good point. In some level I'd prefer the delay to happen on publication of the package itself. Do any of these scanners have cryptographic attestations or similar?
- antonio0720 6mo ago[dead]
- pier25 6mo agoPSA from the Claude Code leaks it looks like it's using Axios (although an older version)
- dryarzeg 6mo ago(A bit off-topic; half-joking, half-serious) What a great time to be alive! Now, that's exactly why I enjoy writing software with minimal dependencies for myself (and sometimes for my family and friends) in my spare time - first, it's fun, and second, turns out it's more secure.
- SoftTalker 6mo agoThis only limits the possibility of compromise, it doesn't remove it. Python itself could be compromised, or the package that your linux distro provides could be. With AI agents the volume and frequency of supply chain attacks is going to explode. I think our entire notion of how to develop and distribute software safely needs to change. I don't have answers; "reflections on trusting trust" explains the difficulties we now face.
- ohsecurity 6mo ago[flagged]
- philipwhiuk 6mo ago> At that point, “npm install” feels less like importing a library and more like executing a supply chain Which is why pre and post install scripts should never had been added.
- bspammer 6mo agoIn case you haven't seen, AI-written comments were recently banned here https://news.ycombinator.com/item?id=47340079 https://news.ycombinator.com/item?id=47340079
- nadav_tal 6mo ago[flagged]
- twodave 6mo agoHow is it we've made it this far and we still don't have any kind of independent auditing of basic publish security on NPM? You'd think this would be collectively a trivial and high priority task (to ensure that all publishes for packages over a certain download volume are going through a session that authenticated via MFA, for instance).
- philipwhiuk 6mo ago> You'd think this would be collectively a trivial and high priority task (to ensure that all publishes for packages over a certain download volume are going through a session that authenticated via MFA, for instance). Because all mainstream packages are published via CI/CD pipeline not by an MFA'd individual uploading a GZIP to npm.com
- zbentley 6mo agoRequiring a human-in-the-loop for final, non-prerelease publication doesn't seem like that onerous of a burden. Even if you're publishing multiple releases a day on the regular (in which case ... I have questions, but anyway) there are all sorts of automations that stay secure while reducing the burden of having to manually download an artifact from CI, enter MFA, and upload it by hand.
- twodave 6mo agoYou can still have a step that requires a certain user/group to sign off, and you can still enforce that those users have MFA set up. Almost any serious shop that expects to pass audits already does this in some form or fashion before pushing code to prod.
- jijji 6mo agoanother week another npm supply chain attack
- ex-aws-dude 6mo agoWhy is it with Javascript the culture is to use so many dependencies?
- zbentley 6mo agoAll sorts of reasons, but this isn't a left-pad situation. Axios's functionality is something provided by a library in a lot of languages (C/C++ with libcurl and friends, Python with requests, Rust with reqwest, and so on). That's not to say it's inherently necessary for it to be a third-party package (Go, Ruby, and Java are counterexamples). But this isn't a proliferation/anemic stdlib issue.
- davikr 6mo agoWhy can't we freeze the version of globally installed packages with npm?
- carlbarrdahl 6mo ago[dead]
- shahmeern 6mo agoScript to check if you've been pwnd if anyone needs it (or just ask an llm to make one for you): https://gist.github.com/shamwow/93101381686f23d21a85da4bac5bcf77 https://gist.github.com/shamwow/93101381686f23d21a85da4bac5b...
- 0xbadcafebee 6mo agoWe're going to see this more and more and more. And it's not going to stop. Because nobody in the industry will use the simplest, industry-standard security practices. Because they don't feel like it. A software building code is the only thing that'll fix it.
- tonymet 6mo ago1/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
- Sidmo2006 6mo agoOfc this happens the day we launch on product hunt. The last time we launched, AWS went down.
- deleted 6mo ago[deleted]
- croemer 6mo agoHas 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 https://github.com/axios/axios/issues/7547 (7547) and ending at https://github.com/axios/axios/issues/10546 https://github.com/axios/axios/issues/10546 (10546 which is 7547+2999) Maybe just a coincidence but they have cubic-dev-ai edit every single PR with a summary. And that bot edits PR descriptions even for outside contributors.
- croemer 6mo agoMaintainer replied here https://github.com/axios/axios/discussions/10612 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.
- Blackthorn 6mo agoDo we have a way yet to tell if something on our system is compromised? There's plenty of end user software built on node, like Gemini CLI and LM Studio.
- socketcluster 6mo agoI'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.
- ezekg 6mo agoAgree. This is one of the major takeaways I've had from writing Go over the years -- which is even a Go proverb [0], "a little copying is better than a little dependency." Fortunately, LLMs make writing your own implementations of little dependencies super easy too. [0]: https://go-proverbs.github.io/ https://go-proverbs.github.io/
- Bridged7756 6mo agoI'll agree with that, and you would think it's common sense for any competent engineer, but for many people it's just an afterthought. Including senior and lead engineers. General matters like security are a political liaison, how can you raise the alarm/advocate for critical security improvements as an IC without making people around and above you look bad? How can you justify time invested into these things without raising the alarm? At the same time, you can't just ignore glaring security holes. It's a fine line to walk, and actually being realistic about the possibilities has found me nothing but enmity from peers and superiors due to it seeming like I'm throwing them under the bus. In general, management was to see progress. I've come to find that technical details like these are an afterthought for most engineers, so far as the deadlines are being met. It's one of these things that are under the water, tech side jobs. Everyone has to be on board, if your peers don't give a fuck you're just an annoyance and will be swimming counter-current.
- socketcluster 6mo agoCan relate. It's like; if you're less rigorous than the CTO, they would think you're incompetent. If you're more rigorous than the CTO, they would think you're overly pedantic; not pragmatic enough.
- flerchin 6mo agoOk it's bad, but our npm projects are pinned in the package-lock.json, which I imagine most would be? So who would pull this besides security scanners?
- OsrsNeedsf2P 6mo agoUpdating my packages feels like playing Russian Roulette
- Serhii-Set 6mo ago[dead]
- cachius 6mo agoUh Axios. Even after being years out of NPM dev I remember that as the XHR thing for node. Whichs rings a big hit even to out of the loop people...
- Willish42 6mo ago> This was not opportunistic. It was precision. The malicious dependency was staged 18 hours in advance. Another obvious ChatGPT-ism. The fact that people are using AI to write these security posts doesn't surprise me, but the fact they use it to write a verbose article with spicy little snippets that LLMs seem to prefer does make it really hard to appreciate anything other than the simple facts in the article. Yet another case in point for "do your own writing" (https://news.ycombinator.com/item?id=47573519 https://news.ycombinator.com/item?id=47573519)
- kjok 6mo agoCurious to know why are coding agents not detecting such risks before importing dependencies?
- mayhemducks 6mo agoI'm assuming you are talking about agents like claude-code and open-code which rely on GPT functions (AKA Large Language Models). The reason they don't detect these risks is primarily because these risks are emergent, and happen overnight (literally in the case of axios - compromised at night). Axios has a good reputation. It is by definition impossible for a pre-trained LLM to keep up with time-sensitive changes.
- kjok 6mo agoI mean that agents can scan the code to find anything "suspicious". After all, security vendors that claim to "detect" malware in packages are relying on LLMs for detection.
- mayhemducks 6mo agoAn LLM is not a suitable substitute for purpose-built SAST software in my opinion. In my experience, they are great at looking at logs, error messages, sifting through test output, and that sort of thing. But I don't think they're going to be too reliable at detecting malware via static analysis. They just aren't built for that.
- classified 6mo agoHow anybody is still using NPM is beyond me.
- Bridged7756 6mo agoAt this point picking Node for a backend is a foot gun. Large companies have the funds for private, security vetted npm repositories, but what about small companies, startups, personal projects? Pnpm makes things more secure without install scripts, mininum package time, but it's still the same activity, does an extra parachute make skydiving any less inherently dangerous? I'm not dogmatic about the whole "JS for the backend is sin" from backend folks, but it seems like it was the right call. You should stick to large org backed packages, or languages with good enough standard libraries, like Go, Java, Python, C#.
- carlbarrdahl 6mo agoMany of the suggestions in this thread (min-release, ignore script) are defenses for the consumers. I've been working on Proof of Resilience, a set of 4 metrics for OSS, and using that as a scoring oracle for what to fund. Popularity metrics like downloads, stars, etc are easy to fake today with ai agents. An interesting property is that gaming these metrics produces better code, not worse. These are the 4 metrics: 1. Build determinism - does the published artifact match a reproducible build from source? 2. Fuzzing survival - does the package survive fuzz testing? 3. Downstream stability - does it break any repos dependent on this project when pushing a release? 4. Patch velocity - how fast are fixes merged? Here's a link to the post, still early but would appreciate any feedback. https://hackmd.io/@carlb/proof-of-resilience https://hackmd.io/@carlb/proof-of-resilience
- Imustaskforhelp 6mo agoCarl, with all due respect, have you used AI for making this hackmd post? "it's not just a waste of money — it's a security problem" I am really passionate about these things, but I am not going to read something which you haven't written. Even sharing a prompt/rough-sketches/raw-writing might be beneficial but I recommend writing it by-hand man, we are all burnt out reading AI slop, I can't read more AI
- carlbarrdahl 6mo agoYou're right, I used an LLM to help write it from sketches. Gonna rewrite it properly because I think the ideas are worth exploring. Thanks for taking the time to read and reply.
- Imustaskforhelp 6mo agoIn my opinion, its okay to use LLM to help find some sources and then validating them (but I also recommend using hand researching too as you might find some good things that you maybe weren't even looking for!) but, please don't use LLM to help write it from sketches. Even show the sketch :) Much of my writing is very sketch-y. Some people don't like it, but its mine and I am proud of it and I hope that even if you write sketches/refine them, you can be comfortable sharing your ideas in your words in the way you wish to write them carl! My thinking is that, I improve my writing by well... practice itself. So I write publically and there are some thoughts which occur in my head during the writing process itself (PG has a good article about it recently) In a world of AI, to me, Human writing is a breath of fresh air. Please don't fall into the rabbit-hole that you might need LLM to help write you. These are just my 2 cents though, but I feel like I am definitely not alone in thinking so. Have a nice day and I am looking forward for you to write the article yourself. Feel free to share me when you do with my mail as I would love to read it, as I am also passionate about the funding of open source :)
- xyst 6mo agoyet 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-658g-p7jg-wx5g https://github.com/usebruno/bruno/security/advisories/GHSA-6...
- pagecalm 6mo agoThis is the part that's tough — we push everyone to keep dependencies updated and automate it with Renovate or Dependabot, but that's exactly the pipeline that would have pulled this in before anyone noticed. Lockfiles and pinning help slow it down, but most teams pair those with automated update PRs which kind of negates the point. You can reduce your dependency surface area to lower the odds but one compromised maintainer on a top-10 package and none of that matters.
- a13n 6mo agoRejecting any packages newer than X days is one nice control, but ultimately it'd be way better to maintain an allowlist of which packages are allowed to run scripts. Unfortunately npm is friggen awful at this... You can use --ignore-scripts=true to disable all scripts, but inevitably, some packages will absolutely need to run scripts. There's no way to allowlist specific scripts to run, while blocking all others. There are third-party npm packages that you can install, like @lavamoat/allow-scripts, but to use these you need to use an entirely different command like `npm setup` instead of the `npm install` everyone is familiar with. This is just awful in so many ways, and it'd be so easy for npm to fix.
- philipwhiuk 6mo agopnpm and bun have approved lists. npm is just dragging it's feet - and stuff like this is why people moved to pnpm, yarn and bun in the first place.
- mdavid626 6mo agoIt’s time to run development in sandboxes. Docker or sandbox-exec (for Mac).
- jeremie_strand 6mo ago[dead]
- pjoubert 6mo ago[flagged]
- jeremie_strand 6mo ago[dead]
- mr_bob_sacamano 6mo ago# If you have a projects folder containing multiple projects on macOS, you can run this script to recursively scan all subfolders for vulnerable axios versions and the presence of plain-crypto-js, helping you quickly identify potentially affected projects: find . -name "package.json" -exec sh -c ' dir=$(dirname "{}") echo "==== $dir ====" cd "$dir" npm list axios 2>/dev/null | grep -E "1\.14\.1|0\.30\.4" grep -A1 "\"axios\"" package-lock.json 2>/dev/null | grep -E "1\.14\.1|0\.30\.4" [ -d node_modules/plain-crypto-js ] && echo "POTENTIALLY AFFECTED" ' \;
- imta71770 6mo ago[dead]
- Mooshux 6mo ago[dead]
- cgrfrog2026 6mo ago[dead]
- mkdelta221 6mo agoThis is the second major npm supply chain attack this year and the playbook is identical every time: hijack a maintainer account, publish via CLI to bypass CI/CD, inject a dependency nobody's heard of. The fix isn't better scanning (though Socket catching it in 6 minutes is impressive). The fix is npm making Trusted Publishers mandatory for packages above a download threshold. If axios can only be published through GitHub Actions OIDC, a stolen password is useless. We run a fleet of AI agents that depend on npm packages. First thing we did tonight was audit every lockfile. Clean — but only because we aggressively minimise dependencies. The real victims here are the thousands of teams who npm install with ^ ranges and never check what changed.
- chrisldgk 6mo agoMy main question here is mostly why so many people still rely on axios for their fetch implementation. Native fetch has been a thing in the JavaScript world for so long, and the DX gains to using axios over it are miniscule. The only thing I can think of is axios instances, but you can easily write a tiny wrapper for fetch that would do the same. This is a genuine question - if you still use axios, why exactly?
- astrostl 6mo agoFWIW I vibe coded https://github.com/astrostl/surplies https://github.com/astrostl/surplies to detect evidence of the Axios and LiteLLM malware, using StepSecurity's writeups as a data source.
- rawgabbit 6mo agoCNN reports it was North Korean hackers. https://lite.cnn.com/2026/03/31/politics/north-korea-hacking-crypto https://lite.cnn.com/2026/03/31/politics/north-korea-hacking...
- 40four 6mo agoThat’s probably the most interesting part of this whole story and it’s nowhere to be found here
- SEJeff 6mo agohttps://docs.npmjs.com/trusted-publishers/#recommended-restrict-token-access-when-using-trusted-publishers https://docs.npmjs.com/trusted-publishers/#recommended-restr... This helps mitigate spear phished privileges employees pushing hacked npm packages entirely.
- navilai 6mo ago[dead]
- pratyushsood 6mo ago[dead]
- jeremie_strand 6mo ago[dead]
- navilai 6mo ago[dead]
- HironoOcto 6mo ago[dead]
- jamiemallers 6mo ago[dead]
- summitwebaudit 6mo agoThe 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.
- efilife 6mo agoI haven't seen a bot here insert a \n into a comment yet
- edf13 6mo ago[dead]
- robshippr 6mo agoThree hours between the malicious publish and npm pulling the versions. If your CI ran an install during that window, this went straight to prod. Most teams I've worked with still have loose version ranges somewhere in their dependency tree even if they think they've locked everything down.
- jeremie_strand 6mo ago[dead]
- K0IN 6mo agoSo here is the pitch: for npm / a new registry 1. Only the registry itself can build packages (only source provided) 2. Builds must be reproducable (no network or external files during build / publish) 3. New versions are hidden by default 4. Releases can only be published by an account, using a hardware 2fa token + password (no persistent login, no long lasting token) 5. All commits must be signed (maybe block web commits or add a cooldown of a few days?) 6. builtin scanners (using ai, virustotal, existing services) 7. if a security violation is found the version is instantly removed 8. Atleast 1 - 3 Days delay for releases 9. Hard no on binaries / post install scripts and binary data 10. blockchain like public record to see who published, updated, owns what
- gbibas 6mo ago[dead]
- sonexy 6mo agoGitHub PR links
- asen_not_taken 6mo agoAxios has been one of my favorite libraries for over a decade. However, I must say I have never used it since starting vibe coding.
- aeneas_ory 6mo agoI wrote a tool that helps you check if your machine was compromised: https://github.com/aeneasr/was-i-axios-pwned https://github.com/aeneasr/was-i-axios-pwned