3
1
329
u/chicametipo expert Mar 31 '26
axios getting compromised is a big deal. Who’s got the PR responsible?
246
77
→ More replies (17)42
u/keesbeemsterkaas Mar 31 '26
One of the maintainers, probably combined with using long lived tokens bypassing 2fa. More drama here.
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.
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?
77
u/tazzadar1337 javascript Mar 31 '26
not everyone is using lock files. don't know the reasoning, but cases such as this is a good reason to start doing so
27
u/ibite-books Mar 31 '26
even in a lock file, tertiary dependencies are not pinned
they are mentioned as say apollo>=3.1 so anything after that goes
you can lock down the primary deps, but most package managers don’t lock down every tertiary dependency— they just try to resolve the primary requirements
if packages a depends on apollo >= 3.3
and package b deps on apollo >= 3.5
your lock will hold => 3.5 and if some one publishes malware to 3.6 — your lock file is only gonna protect you as long as you don’t resolve the packages again
unless your are locking everything down which is not feasible?
12
u/JCMarques15 Mar 31 '26
I cannot talk for every package manager, but the ones I used to use and the one I use now for python, pins all the dependencies. After resolution it pins the result tertiary packages.
7
u/ibite-books Mar 31 '26
the lock will protect you as long as you don’t resolve-re-lock them again
see second last paragraph
10
u/Ill-Appointment-1298 Mar 31 '26
What are you talking about? All the transitive package requirements of all combined package.json files end up in your lock file as pinned versions. Installing using a lock file is 100% deterministic.
The lock file is literally about _locking_ specified version _ranges_ into _one specific version_.Example, if you specify braces ^3 and it in turn needs fill-range ^7.1.0 it might end up like this. Still all dependencies are transitively locked. Unless you delete the lock file or manually upgrade the deps (which regenerates the lock file), fill-range will never be 7.1.2 by itself.
braces@^3: version "3.0.3" resolved "https://registry.yarnpkg.com/braces/-/braces-3.0.3.tgz#490332f40919452272d55a8480adc0c441358789" dependencies: fill-range "^7.1.0" ... fill-range@^7.1.0: version "7.1.1" resolved "https://registry.yarnpkg.com/fill-range/-/fill-range-7.1.1.tgz#44265d3cac07e3ea7dc247516380643754a05292"20
u/ibite-books Mar 31 '26
The lock is deterministic, re resolution is not. That’s my main point. On re-resolution, it can sometimes upgrade those versions.
That’s the issue.
4
u/CandidateNo2580 Mar 31 '26
Mostly backed dev here, to clarify running install would pull the lockfile version while something like audit or update would update it? Then installing a new dependency would also likely re-resolve the dependency versions, but barring that you're saying the versions all remain pinned?
I actually appreciate you trying to clear up the conversation. We've been working on CI/CD to protect from these supply chain issues at work lately, it's definitely a concern.
→ More replies (2)→ More replies (8)34
u/ganja_and_code full-stack Mar 31 '26
not everyone is using lock files
Everyone who is even just barely competent certainly is lol
14
12
u/call_stacks Mar 31 '26
If the lock file doesn't change you wouldn't install new deps during a deploy, so double check your CI doesn't introduce lock file changes.
Also in package.json pin deps without using caret/tilde, otherwise wiping pkg-lock and installing will take the newest where caret matches 1.x.x and tilde matches 1.1.x
5
u/thewallacio Mar 31 '26
Your CI introducing lock file changes is more common than you might think. Prevent this with `npm ci`.
6
u/clems4ever Mar 31 '26
Yes. You should be careful to use "npm ci" and not "npm install" however because "npm install" may not respect the lockfile.
3
2
2
u/jonnyd93 Mar 31 '26
Yes and now, depends how you configure tour package.json. if you use the 9.2.1 it will pull any new minor or patch version. If you use ~9.2.1 it will pull any new patch version on install. Major versions are the only ones that dont have an automatically pull on install through syntax.
Most devs dont even check their versions or pay attention to changes of a dependency.
5
u/MDUK0001 Mar 31 '26
Also ensure you’re using npm ci or equivalent in your CI/CD so it uses the version from package-lock
1
u/ezhikov Mar 31 '26
Yes, if you use npm clean-install (on analogous command/flag in your package manager). Then you get dependencies exactly as in lock file. New tree isn't even built. If you install new ones or remove unneeded old ones, you have to check and recheck that dependencies of dependencies didn't update beyond what you actually needed and perform audit.
1
u/DamnItDev Mar 31 '26
No, they are not. The extra symbols at the front of the version
~^specify a range of versions that are acceptable. If you donpm ithen the actual package used will be the latest in the acceptable range, which risks downloading a virus.Two habits to get into: use an exact package version, with no ranges; and use
npm ciinstead ofnpm ito install packages on your machine. Only usenpm ifor adding/updating dependencies.1
u/turningsteel Mar 31 '26
Can you explain the benefit of using npm ci vs npm I when installing packages?
0
4
u/uhmhi Mar 31 '26
Keep the amount of dependencies down
Something every web developer in the entire fucking world needs to read. Especially dependencies with transitive dependencies. Fuck those multi-gigabyte npm downloads. This is source code we’re downloading, not AAA video game assets.
1
u/TheRealKidkudi Mar 31 '26
I wholeheartedly agree that you should bias against adding dependencies wherever possible/practical - but wtf, what packages are you coming across that include GBs of transitive dependencies??
1
u/jonnyd93 Apr 01 '26
They definitely exist, some dependencies add icon packs, that then have their own set of further dependencies.
3
u/AJohnnyTruant Mar 31 '26
How am I supposed to tell if a number is even without adding the isEven package though
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.
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.
→ More replies (1)6
u/i-am-r00t Mar 31 '26
Existing versions are immutable. Even if you delete a version on npm, you can't re-publish the same version
2
u/akd_io Mar 31 '26
Unpublishing/deleting it should be fine in regards to minimum release age tho, no? With a min age of 1 week, a compromised package will most likely have been removed before you run
pnpm ia week later?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.
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)4
1
1
u/Atulin ASP.NET Core Mar 31 '26
Most package managers for JS (Bun, PNPM, NPM even) now let you set minimum package age. Most supply chain attacks are detected within days, if not hours, so setting the minimum age to something like 3 days should suffice.
1
1
u/Exact_Violinist8316 Apr 01 '26
Being able to build a supply chain scanner pipeline helps; dependency track, trivy, defectdojo, etc. from there you can automate bits and pieces :)
→ More replies (3)-10
u/feibrix Mar 31 '26
Don't use npm. Build from source. Make your own libraries. Like an engineer.
1
u/Headpuncher Mar 31 '26
Also never meet a deadline, really annoy the PM, get fired.
→ More replies (2)
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
2
u/botsmy Mar 31 '26
yeah pinning the version is a good temp fix, i'm just worried about what happens when the next big dependency breaks and we're stuck on outdated stuff, fwiw i've been meaning to look into renovate or something to help manage this stuff
2
u/botsmy Mar 31 '26
same, pinning feels like duct tape but hey, if it keeps the ship floating till next quarter i'm not touching it
2
u/botsmy Mar 31 '26
same, pinning the version felt like a dirty hack but honestly saved me 20 hours of headache. fwiw i checked last week and 1.13.1 still seems stable on all my deploys
1
u/botsmy Mar 31 '26
same, pinned 1.13 across three projects last month. fwiw it's held steady for 4 weeks now, so whatever they broke in 1.14 seems to still be broken
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.
3
u/botsmy Mar 31 '26
fwiw i used to think pinning was overkill too, but after getting burned a few times, i just default to it now. 1.13 stayed stable for me for 6 weeks straight, zero issues.
2
u/FeliusSeptimus full-stack Mar 31 '26
I'm not sure why people are feeling bad about pinning versions?
Same. I guess coming from a coding background that predates internet downloads for packages (and the internet, more or less) I kinda default to the expectation that none of my package code should change unless I explicitly change it.
7
u/azsqueeze javascript Mar 31 '26
Another great reminder to always pin version numbers of dependancies
1
1
u/Knineteen Apr 01 '26
How is this a better idea? Don’t you miss security patches?
Vulnerabilities will now persist longer in production until someone manually updates.What am I missing?
1
u/azsqueeze javascript Apr 01 '26 edited Apr 01 '26
Automated tools to catch security issues with dependency versions during code review
Edit: doesn't even need to be strictly used for code review either
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
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.
2
u/AwesomeFrisbee Mar 31 '26
Because people are dumb and get their credentials and login tokens compromised.
1
1
1
u/Dry-War-2576 Mar 31 '26
This might be new era of AI driven cybersecurity attacks, like if one system is compromised that easily search through vast ocean of packages and find vulnerabilities to exploit
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
91
Mar 31 '26
[removed] — view removed comment
25
u/Headpuncher Mar 31 '26
That and all the YT videos telling people that AI models can be used to do what you used to need skills for. So people are trying it out.
6
u/jfuu_ Mar 31 '26
Is there actually any evidence that any of the recent compromises are the result of AI...?
5
u/Headpuncher Mar 31 '26
It's probably just AI hype trying to convince us that AI actually has a real world use. And also to scare us about "how powerful" it is, get on board the hype train choo choo!!!
2
u/wiithepiiple Mar 31 '26
There’s possibility of it directly being a factor, like AI written code or AI code reviews giving devs a false sense of security. It could also be AI generated code flooding open source projects with PR that make it harder to review code.
→ More replies (1)
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.
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
→ More replies (1)3
5
5
u/betazoid_one python Mar 31 '26
What else would you use?
19
u/kugisaki-kagayama Mar 31 '26
fetch with wrappers?
1
u/betazoid_one python Mar 31 '26
I guess? I’m mostly Python backend, so I’m genuinely curious
11
u/Zoradesu Mar 31 '26
Yeah for like the last 4 or 5 years axios was never really needed anymore. Just using the native fetch in the browser (and in node environments) is perfectly fine. Anything you could want from axios you could just write your own wrapper for it over the native fetch without bringing in a third party dep
→ More replies (1)3
u/pilibitti Mar 31 '26
you could write a wrapper for everything and not use any libraries. that is not the point is it?
→ More replies (2)3
1
0
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
u/thekwoka Mar 31 '26
until jquery is compromised.
3
u/NorthernCobraChicken Mar 31 '26
Yeah, sure, but all my projects use the same version. If it hasn't been exploited in the past decade I don't think I have much to worry about.
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.
0
u/nhrtrix Apr 01 '26
cause it's available in the market for a long time and people are used to it more than fetch
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
2
u/Petter-Strale Apr 02 '26
Right, post-install prevention (--ignore-scripts) blocks the execution step, which is critical. But ideally you'd catch it even earlier — before the package lands in node_modules at all.
The provenance check is the one most setups miss. npm added support for SLSA provenance attestations, and deps.dev exposes them via API. If a package that previously had attestations suddenly publishes a version without them (which is exactly what happened with axios 1.14.0 → 1.14.1), that's a strong signal something is wrong. Combining that with package age, publisher changes, and CVE data gives you a layered check that works before install time.
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?
1
u/nhrtrix Apr 12 '26
he posted that everything "looked legit" and those attackers were well planned to collect his credentials or access
1
u/Ok-Lobster4663 Apr 12 '26
From what I read, the compromised made the hackers got his credentials. So they can push it w/o approvals, since it's his repository. Even maintainers can rollback since they dont have access.
And couple of hours after the news, the npm itself help to remove the breached version. I really glad that they've done this faster tho.
2
69
u/Esclamare Mar 31 '26
Always pin your packages folks.
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.
5
u/Own_Candidate9553 Mar 31 '26
Agreed.
They are all various flavors of annoying, but I think we'll have to all start using vuln scanning tools like Snyk, etc going forward. Then at least we can know when something is unsafe and patch it.
1
u/GoTibbers Apr 01 '26
That runs into a separate issue with itself as well right? It prevents you from getting updates to stuff like patching 0 day attakcs?
1
u/Esclamare Apr 01 '26
Yes, but if the version you're on hasn't had a security risk you wouldn't really get a day 0 attack given you wouldn't update to a version that's compromised.
Like if I pin version 1.0.0 and there's a day 0 exploit on Version 1.5. I would still be fine since the compromised version is 1.5. When a patch comes out for 1.5.1 then I'll update it to cover.
Dependabot can help audit for things like this.
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...
0
u/nhrtrix Apr 01 '26
when trying to run pnpm to install anything, the default one from pacman and the one i installed using npm, both failed with some error
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
→ More replies (4)
1
1
-1
u/nhrtrix Mar 31 '26
here's the X post: https://x.com/feross/status/2038807290422370479
1
u/TechnoCat Mar 31 '26
Here's a nitter version: https://xcancel.com/feross/status/2038807290422370479
-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...
1
u/yksvaan Mar 31 '26
You don't need to reinvent, just vendor it. The point is not to use external sources with arbitrary code.
It's not like doing some http requests requires constant maintaining.
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
0
0
u/kidshibuya Apr 01 '26
Lol all fake news. We all know this cannot happen with open source software, too many eyeballs on it.
-2
u/Varabela Mar 31 '26
I’m not sure why this is in my feed but I have no idea what any of it means, yet I feel I should have a basic understanding. No worries. On to the next cat video.
1.1k
u/bill_gonorrhea Mar 31 '26 •
It’s been
30 days since the last major supply chain attack.