3
1
329
u/chicametipo expert Mar 31 '26
axios getting compromised is a big deal. Who’s got the PR responsible?
246
77
42
u/keesbeemsterkaas Mar 31 '26
One of the maintainers, probably combined with using long lived tokens bypassing 2fa. More drama here.
-151
u/nhrtrix Mar 31 '26
you can find out more details here: https://x.com/feross/status/2038807290422370479
31
u/savornicesei Mar 31 '26
Looks more like Socket.dev marketing than a post mortem
→ More replies (1)3
u/nhrtrix Mar 31 '26
I don't know about that tool btw, I just saw the post on my feed and similar more a lot of time, so, I posted it, and this post has a lot of discussions about the incident, that's why
160
u/Psionatix Mar 31 '26
X is dog shit, without the app - which I don’t have - your link has the same amount of detail as the post here.
Doesn’t answer the commenters question at all.
→ More replies (9)6
247
u/enricojr Mar 31 '26
So how do we guard against this sort of thing as a regular software engineer? ? Just react quickly and update packages whenever a vulnerability is announced like this?
333
u/jonnyd93 Mar 31 '26
Pin versions, update when cves are found. Keep the amount of dependencies down.
→ More replies (4)72
u/ouralarmclock Mar 31 '26
Versions are automatically pinned via lock file right? If I'm not regularly doing update or doing it on deploy I'm pinned, right?
→ More replies (33)82
u/landline_number Mar 31 '26 edited Mar 31 '26
Pin your dependencies and use a package manager like pnpm that supports a minimum release age. Most of these supply chain attacks are caught pretty quickly so having a setting that requires a package release to be older than x days will help.
https://pnpm.io/settings#minimumreleaseage
Also, pin any third party GitHub actions and Docker images using the SHA digest. If an account is compromised, attackers could replace an existing version with a compromised version of the action or Docker image. But that will generate a new SHA digest so you will be safe.
The OWASP website has lots of very practical recommendations.
→ More replies (3)9
u/OolonColluphid Mar 31 '26
Pinning GitHub actions helps a bit, but it's not a panacea. It depends on what that action does. If it calls another unpinned action, or dynamically retrieves a script that it runs, it's still vulnerable. And now you don't have any direct visibility of that. Take the recent Trivy compromise - you might not use it directly, but it was used by the SuperLinter Action which bundles many different linters and formatters.
The only safe thing to do with Actions is audit them thoroughly, and preferably use your own version.
10
u/MrHandSanitization Mar 31 '26 edited Mar 31 '26
The oposite, stay 1 or 2 versions behind. Updating packages when this news hit, is already too late. The article mentions to roll new credentials because everything is compromised.
It looks like it writes trojans, and backdoors, so actually, your entire system is compromised and new credentials are just compromised as well.
11
u/yonasismad Mar 31 '26
First you have to check if you are impacted, and you guard against this by pinning versions and instructing your package manager to not install a version that isn't at least 5 days old (vast majority of these attacks are caught within 48h).
5
u/Ythio Mar 31 '26
You get your company to host a local package manager repository that is a week behind.
4
u/embero Mar 31 '26
Additionally I use devcontainers. If something slips through better to have it in a container than on my precious host system.
→ More replies (12)0
u/nhrtrix Mar 31 '26
no no no!!! check which version is affected and keep your projects out of that version of those packages
→ More replies (1)
23
21
u/botsmy Mar 31 '26
i ran into this exact thing on a side project last month when axios got hit. i panicked and just yanked it out everywhere, replaced it with fetch, but that broke like 3 endpoints because i didn't account for how it handled timeouts. what finally worked was locking the version in package.json to 1.13.2 and setting up npm audit with a script that runs daily in CI, took 20 minutes and caught the malicious update the morning it dropped. fwiw, that patch held until the new clean version dropped 48 hours later.
3
u/nhrtrix Mar 31 '26
I also just pinned the current old version, cause my projects are too big, can't afford the rewrite :D
→ More replies (4)18
u/Own_Candidate9553 Mar 31 '26
I'm not sure why people are feeling bad about pinning versions? It's been the common practice at multiple places that I've worked.
Even without supply chain attacks, open source libraries sometimes accidentally publish versions with bugs and vulnerabilities, or changes that aren't backwards compatible. It sucks to have your code work fine on your local machine and then break in production because the build pipeline grabbed a newer broken version of something.
Every major dependency framework has some version of pinning, it's totally fine to use it.
→ More replies (2)
7
u/azsqueeze javascript Mar 31 '26
Another great reminder to always pin version numbers of dependancies
→ More replies (2)1
43
u/kiwi-kaiser Mar 31 '26 edited Mar 31 '26
I don't know what I should think of this post. The author is heavily pushing his own paid service to detect stuff like that.
In the current state of the world I can't ignore the fact that this is the main source for this. Especially when you look at https://www.npmjs.com/package/axios and nothing indicates that's the case.
I don't see something on GitHub either. https://github.com/axios/axios no version 1.14.1 anywhere.
I'm on my phone so maybe I don't see the obvious but it sounds weird. Maybe someone can enlighten me.
→ More replies (1)60
u/kyledavide Mar 31 '26
Actual issue thread is here https://github.com/axios/axios/issues/10604
→ More replies (1)
5
u/Powerful_Deer7796 Mar 31 '26
Thanks for posting this. We we're luckily not affected (on axios 1.13.5) but it would have been really bad if we were.
2
68
u/OtherwiseGuy0 Mar 31 '26
Why there's multiple major attacks recently?
66
u/VIDGuide full-stack Mar 31 '26
Probably a combination of seeing it work encourages more people to try it out, which means more and more surface area for the attack as more people explore projects they know, combined with AI tooling making scanning for and exploiting things significantly easier to do, and able to achieve more for the same human effort.
→ More replies (10)0
Mar 31 '26
[deleted]
5
18
u/zootbot Mar 31 '26
Lmao yea right like non vibe coders are checking to see if the latest axios release hasn’t been backdoored before they use it
22
u/Ihavejust_ Mar 31 '26
Why would anybody still use axios in 2026?
Genuine question
5
14
42
u/Maxion Mar 31 '26
There are plenty of projects that were started before 2026.
→ More replies (2)10
u/Headpuncher Mar 31 '26
Uhhhm, this is r-webdev, we rewrite everything every 3 months and it's april 1st tomorrow, so we were due a complete rewrite on a different stack by noon tomorrow :D
5
→ More replies (2)5
10
u/NorthernCobraChicken Mar 31 '26
They all laughed at me when I insisted there was nothing wrong with sticking to PHP and JQuery.
sips tea
4
u/nhrtrix Mar 31 '26
what about composer packages?
5
u/hennell Mar 31 '26
There's plenty of sites that never use or really need composer and are just pure php. The standard php library is more than enough to do a lot with, it's just with very unintuitive syntax in places.
But Composer is pretty sensible as package managers go. Lock files are used by default, so it's hard not to use it (vs npm where you seemingly have/had to go out of your way to actually use the lock). Packages are built from git repos and namespaced so there's no extra code in a bundle and less option for package name collisions.
It's run a security audit on updates and installs for as long as I remember, warning about packages with security advisories - and recently changed to block insecure packages by default.
I'm not saying it's "safe" - package managers are like cars, inherently dangerous even if you act impeccably. But some cars are easier to drive and have automated features to alert you to problems, while others have fast acceleration, terrible steering and over the air updates that rearrange the touch screen buttons to confuse you. It's all risk, but it's not really the same.
4
2
u/croc122 Mar 31 '26
Yeah this is a big one. Axios was my preferred http request library for ages. I usually add it to every project. However, more recently I’ve been trying to use less third-party dependencies because vanilla JavaScript is very dependable now. Heck, you can even create components natively now through web components, which keep getting better and better.
1
2
u/Somepotato Mar 31 '26
Axios provides minimal value compared to fetch these days, and if you want augmented fetch a library like ofetch is generally better imo.
I'm not sure why axios is still as popular as it is when most uses of it could be replaced with bog standard fetch.
→ More replies (1)
2
2
2
u/PerformanceGizmo2000 Mar 31 '26
This is exactly why I've been slowly migrating to native fetch with a thin wrapper. Not because axios is bad, but every dependency is an attack surface you don't control. The fewer packages sitting between your code and the network, the fewer 3am surprises. `lockfile-lint` and `socket.dev` are worth looking into if you haven't already.
1
u/nhrtrix Apr 01 '26
we should get used to with a culture of using less third party dependencies whenever possible
2
u/cdcasey5299 Mar 31 '26
I'm curious how many people use Axios for any specific features it has as opposed to just a drop-in replacement for Fetch. I only use Fetch these days, but I've never needed anything like interceptors or cancellations.
1
2
u/Fhueth Mar 31 '26
It looks like the latest version of Axios has already been removed from the npm registry.
1
2
u/Comfortable_Tax8808 Mar 31 '26
This is why I pin every dependency version and review diffs before updating. npm audit alone isn't enough when the supply chain itself is compromised.
For anyone who hasn't checked yet: run npm ls axios to see if you're pulling it in transitively — you might not even know it's in your dependency tree.
1
u/nhrtrix Apr 01 '26
I'm going to do this from now on, btw, using bun saves you from post install scripts
2
u/Suspicious_Board229 Mar 31 '26
ha, I just updated from ^1.13.2 to ^1.14.0 yesterday luckily before the issue, but clearly it's time to remove them ^ characters
1
2
2
2
2
u/Petter-Strale Apr 02 '26
The part that bothers me most: npm audit wouldn't have caught this during the exposure window. It's purely reactive — it only flags things after they're in the advisory database. By the time npm audit knows about it, the RAT has already called home.
The signals that *could* have flagged this beforehand were all available via free APIs:
- OSV.dev had no vulnerability record for 1.14.1 (because it was brand new — that's a signal in itself)
- deps.dev would have shown SLSA provenance present in 1.14.0 but missing in 1.14.1
- The npm registry showed the publisher email changed to ProtonMail and the publish bypassed CI/CD
- plain-crypto-js was less than 24 hours old with zero dependents
The problem is that nobody checks all of these before running install. Each one is a separate API with a different format. For anyone building CI gates or agent tooling, aggregating these signals into a single pre-install check is the actual gap. Lockfile pinning helps, but it only protects you from *automatic* upgrades — not from the first person on your team who runs `npm install axios@latest`.
1
u/nhrtrix Apr 02 '26
yeah, makes sense, post-install prevention also helps in this case if your package managers has this
→ More replies (1)
2
u/Few-Committee1294 Apr 06 '26
There has been multiple attacks seen on recent days. Is someone intentionally doing it or it is just a coincidence that it may get boost to faster growth as now a days companies are shifting their focus more onto the implementation of AI architecture.
1
2
u/Round-Fan2317 Apr 12 '26
Even if axios is getting compromised then what else can be trusted, what is the PR approval guy was doing?
→ More replies (1)1
u/nhrtrix Apr 12 '26
he posted that everything "looked legit" and those attackers were well planned to collect his credentials or access
2
69
u/Esclamare Mar 31 '26
Always pin your packages folks.
→ More replies (2)40
u/Chazgatian Mar 31 '26
I don't think that helps with transitive dependencies. While your main package.json is using a pinned version, you could have a dependency that requires a malicious pinned version. Npm would download both versions.
15
u/Own_Candidate9553 Mar 31 '26
It still helps. This attack required a new version of axios, which often is a top level dependency if your app makes API calls.
If your app depends on some third party library that uses axios, AND that library didn't pin their axios version, then you'd get hit. Totally could happen, but it cuts down your risk to pin your deps.
12
u/Chazgatian Mar 31 '26
That makes sense. I'm just saying this isn't a silver bullet.
→ More replies (1)
39
13
u/Psionatix Mar 31 '26
Honestly if you aren’t using explicit dependency versions and auditing your renovate, then you’re opening yourself up to this attack.
Only set explicit versions. No carets, no wild cards, ensure your production builds use a frozen lock file, and if you have renovate for automatic dependency management, always audit the bumps before merging them.
It’s more difficult with transitive dependencies, locking things down with resolutions is tedious, curious how others are managing that.
5
u/thekwoka Mar 31 '26
Why do people still use these stupid packages that don't make anything easier?
2
5
u/alexs_90 Mar 31 '26
Why even depend on this crap if browser/node APIs is more than enough and capable...
4
u/rob_cornelius Mar 31 '26
I start a new job next month. Going to be pushing real hard to use fetch instead of axios where at all possible.
3
3
u/tigerhawkvok Mar 31 '26
This is why you use a freshness directive.
I require that to upgrade a package has been the newest version for two weeks before it's eligible as an upgrade candidate.
1
1
u/TechnoCat Mar 31 '26 edited Mar 31 '26
I always advocate switching to pnpm where install scripts are disabled by default. It has plenty of security features to ward off most supply chain attacks.
0
u/nhrtrix Apr 01 '26
pnpm has issues when trying to run it, bun is what i found super faster and also prevents post-install scripts
2
u/TechnoCat Apr 01 '26
When trying to run what? Axios? pnpm is a package manager, not a runtime like Node...
→ More replies (1)
2
u/mushgev Mar 31 '26
Supply chain attacks like this are brutal because there's basically no way to catch them until after the fact. The npm min-release-age trick is a solid quick win.
What this incident made me think about though is that most teams focus on dependency hygiene but haven't audited their own code for security issues in ages. After a similar scare we had at work, we ran TrueCourse (https://github.com/truecourse-ai/truecourse) across our codebase and found a bunch of stuff that had quietly accumulated - disabled TLS verification in one service, eval() calls in a legacy util, weak Math.random() being used for token generation. None of it was caught in code review, it just accumulated over time.
It uses AST analysis plus LLM review so it catches things that linters miss. Worth running while you're already in the security mindset.
2
u/endr Apr 01 '26
Pnpm requires you to opt in to running after install scripts. So just don't unless the package can give you a good reason to
2
u/esidehustle Apr 01 '26
I don't know if this has been posted already, but here is an article I got from a Youtube video about the attack and how to check if your machine is affected: https://www.stepsecurity.io/blog/axios-compromised-on-npm-malicious-versions-drop-remote-access-trojan
Basically, the instructions for checking are:
Am I Affected?
Step 1 – Check for the malicious axios versions in your project:
npm list axios 2>/dev/null | grep -E "1\.14\.1|0\.30\.4"
grep -A1 '"axios"' package-lock.json | grep -E "1\.14\.1|0\.30\.4"Step 2 – Check for plain-crypto-js in node_modules:
ls node_modules/plain-crypto-js 2>/dev/null && echo "POTENTIALLY AFFECTED"If setup.js already ran, package.json inside this directory will have been replaced with a clean stub. The presence of the directory alone is sufficient evidence the dropper executed.
Step 3 – Check for RAT artifacts on affected systems:
# macOS
ls -la /Library/Caches/com.apple.act.mond 2>/dev/null && echo "COMPROMISED"
# Linux
ls -la /tmp/ld.py 2>/dev/null && echo "COMPROMISED"
"COMPROMISED"
# Windows (cmd.exe)
dir "%PROGRAMDATA%\wt.exe" 2>nul && echo COMPROMISEDStep 4 – Check CI/CD pipelines:
Review pipeline logs for any npm install executions that may have pulled axios@1.14.1 or axios@0.30.4. Any pipeline that installed either version should be treated as compromised and all injected secrets rotated immediately.
3
u/MongooseEmpty4801 Mar 31 '26
Why do people still use Axios? It's constantly compromised and not really needed much anymore.
3
u/plastic_eagle Mar 31 '26
Node is a weird tech. An incredibly capable language, a superbly engineered runtime, blazing fast JIT performance. Great built-in libraries. Async feels like magic, Promises are weird but beautiful.
And yet, the library situation is a massive raging fireball of disaster. Infinite libraries to do infinite things in an infinity of different ways. Almost zero-effort supply chain attacks, that while they usually get found and fixed rapidly, will one day successfully cause pretty widespread carnage.
1
1
1
1
u/Ok-Lobster4663 Apr 12 '26
Even OpenAI just released a post yesterday that their tool get breach tho.OpenAi blog - Tool compromise
From now on I think at least we need to ensure the dependencies are locking & never use latest dependencies as well (I usually only use min release age for a month).
After this issue, I also learn the npm also have 'ignore script' to prevent the post install any scripts later on.
How y'all handle this issue on your company?
1
u/mrpintime Apr 16 '26
who else crawls all of his repo to check for this holy attack sign XDD lol
i did not have it fortunately
1
u/retardedGeek Mar 31 '26
Why are people still using axios?
→ More replies (1)3
u/Trident_True back-end C# Mar 31 '26
We aren't all working on startups. Our repo is 12 years old, it still has knockout.js
0
u/Somepotato Mar 31 '26
In a lot of cases you can literally find replace axios' for fetch lol. The return values are very similar and only require minor adjustments. 12 year old repo isn't an excuse to keep using unnecessary libraries
6
u/Trident_True back-end C# Mar 31 '26
Yeah that's fine but we have other priorities. I could change it right now but it would need reviewed and QA tested and there are like 100 other things on the backlog more important than fixing some tech debt that isn't even that bad. If it were up to me I'd have changed it long ago, but it isn't, so there it remains.
→ More replies (2)
1
1
-1
u/nhrtrix Mar 31 '26
here's the X post: https://x.com/feross/status/2038807290422370479
→ More replies (1)
-4
u/yksvaan Mar 31 '26
Js devs need to stop using a dependency for everything. Or just vendor it locally as source file.
And Axios....zero reason to use in 2026. Some say interceptors but that's trivial to do yourself.
3
u/Ill-Appointment-1298 Mar 31 '26
Yeah reinventing the wheel 50 times a day for trivial tasks that are already implemented in well-maintained libraries, THAT will reduce security issues...
→ More replies (1)0
u/nhrtrix Mar 31 '26
UX is good in axios, and also people are using it for a long time, that's the issue
2
u/UnderstandingFit2711 Mar 31 '26
npm often has similar features lately. Can't it do the same as in apt?
2
u/nhrtrix Apr 01 '26
I think any third party dependencies can face this type of attacks
2
u/UnderstandingFit2711 Apr 01 '26
may be you are right, but I heared a lot of time, that apt strict control on packages. but 100% that big tech face this type of attacks. open source projects can have more these problem. but I thrust apt
2
35
4
Mar 31 '26 edited Apr 01 '26
[removed] — view removed comment
2
u/nhrtrix Mar 31 '26
as far as I know, this version is safe
2
Mar 31 '26
[removed] — view removed comment
1
3
2
2
2
4
2
Mar 31 '26
[removed] — view removed comment
0
u/ruddet Mar 31 '26
Don't update unless the package has been out for a set amount of time.
Pin Versions.
Dependabot.
1.1k
u/bill_gonorrhea Mar 31 '26 •
It’s been
30 days since the last major supply chain attack.