Side note. I'm sure many of you know this, but for those who don't, setting min-release-age=7 in .npmrc (needs npm 11.10+), would have made the malicious axios (@1.14.1 and @0.30.4) invisible to npm install (removed within ~3h). Same for ua-parser-js (caught within hours) and node-ipc (caught in days). It wouldn't have prevented event-stream (over 2 months), but you can't win them all.
Some examples (hat tip to [2]):
~/.config/uv/uv.toml
exclude-newer = "7 days"
~/.npmrc
min-release-age=7 # days
~/Library/Preferences/pnpm/rc
minimum-release-age=10080 # minutes
~/.bunfig.toml
[install]
minimumReleaseAge = 604800 # seconds
[0] https://nodejs.org/en/blog/announcements/v18-release-announc...
[1] https://nodejs.org/en/blog/release/v21.0.0
After an incident as widely publicized as Axios, I'd expect dependency auditing, credential rotation, and public incident communication to all be carried out with much more urgency. And if they were going to send this out to all of their users (as they should), I would expect _that_ to happen shortly after publishing the post (why wait 11 days???).
You could equally say that using fetch means that the developers don't know how to use axios.
They do the same thing, except axios does it a little better, when it doesn't pwn you.
Axios predates the availability of fetch in node by 2 years, and fetch has never caught up with axios so there was no reason to switch to fetch, unless you need to run on both client and server then of course you use fetch.
I am totally with you on axios; but why is express shocking, and what do you expect to see in its place? Fastify? Hono? Node:http?
https://github.com/sindresorhus/ky
From the readme:
- Simpler API
- Method shortcuts (ky.post())
- Treats non-2xx status codes as errors (after redirects)
- Retries failed requests
- JSON option
- Timeout support
- Upload and download progress
- Base URL option
- Instances with custom defaults
- Hooks
- Response validation with Standard Schema (Zod, Valibot, etc.)
- TypeScript niceties (e.g., .json() supports generics and defaults to unknown, not any)
Of course, this is only for projects where I have to make a lot of HTTP requests to a lot of different places where these niceties make sense. In most cases, we're usually using a library generated from an OpenAPI specification and fall back to `fetch` only as an escape hatch.
That's a pretty big asterisk though. Taking on a supply chain risk in exchange for reducing developer friction is not worth it in a lot of situations. Every dependency you take increases your risk of getting pwned (especially when it pulls in it's own dependencies), and you seriously need to consider whether it's worth that when you install it.
Don't get me wrong, sometimes it is; I'm certainly not going to create my own web framework from scratch, but a web request helper? Maybe not so much.
For reference: https://github.com/sampullman/fetch-api/blob/main/lib/fetchA...
I don't blame you, took me awhile to find the date.
Fetch is one of those things I keep trying to use, but then sorely regret doing so because it's a bit rubbish.
You're probably reinventing axios functionality, badly, in your code.
It's especially useful when you want consistent behaviour across a large codebase, say you want to detect 401s from your API and redirect to a login page. But you don't want to write that on every page.
Now you can do monkey patching shenanigans, or make your own version of fetch like myCompanyFetch and enforce everyone uses it in your linter, or some other rubbish solution.
Or you can just use axios and an interceptor. Clean, elegant.
And every project gets to a size where you need that functionality, or it was a toy and who cares what you use.
(Source: have built out much more scuffed variants of this than the one I just described like https://github.com/boehs/ajar)
I guess a LLM can do as well. Although that's not something I'm quite ready to admit.
What's the reason to switch to something less stable short/long term? Because its older and newer code is always better?
Didn't mean it as an ad btw, the supply chain risk is real though. Axios could be the best HTTP library ever written and it still would've dropped a RAT on your laptop on March 31 without min-release-age set.
Axios is something where you get most of that work done for you by the community for free, and a lot of people know it. As long as you don’t get pwned due to it. Oh and you will actually find community packages that integrate with it, vs ourFetch, which again, nobody knows or even cares that it exists.
Applies to web frameworks, databases and other types of software and dependencies - if you work with brilliant people, you might succeed rolling your own, but for most people taking something battle tested, something off the shelf is a pretty sane way to go about it.
In this case it’s a relatively small dependency so it’s not the end of the world, but it’s the exact same principle.
It's the difference between using a SQL library and some person on your team writing their own SQL library and everyone having to use it. There's a vast gulf between the two, professionally speaking.
People dissing axios probably suffer from other NIH problems too.
An alternative world-view is: "A little copying is better than a little dependency," from https://go-proverbs.github.io
Does become subjective about what "small" and "little" are though.
I think the ideal model would be being able to depend on upstream code, but being able to review ALL of the actual code changes when pulling in new dependency versions (with a nice UI) and being able to vendor things and branch off with a single command whenever you need it, so you don't have to maintain it yourself by default but it's trivial when you want to.
It's actually surprising that in regards to front end development the whole shadcn approach hasn't gotten more popular. Or anywhere else for that matter, focusing on making code way more easy to maintain, to compile/deploy, with less complexity along the way.
We recently identified a security issue involving a third-party developer tool, Axios, that was part of a widely reported, broader industry incident(opens in a new window). Out of an abundance of caution we are taking steps to protect the process that certifies our macOS applications are legitimate OpenAI apps. We found no evidence that OpenAI user data was accessed, that our systems or intellectual property was compromised, or that our software was altered.
We are updating our security certificates, which will require all macOS users to update their OpenAI apps to the latest versions. This helps prevent any risk—however unlikely—of someone attempting to distribute a fake app that appears to be from OpenAI. You can update safely through an in-app update or at the official links below:
The security and privacy of your information are a top priority. We’re committed to being transparent and taking quick action when issues arise. We're sharing more technical details and FAQs below.
On March 31, 2026 (UTC), Axios, a widely used third-party developer library, was compromised as part of a broader software supply chain attack.(opens in a new window) At that time, a GitHub Actions workflow we use in the macOS app-signing process downloaded and executed a malicious version of Axios (version 1.14.1). This workflow had access to a certificate and notarization material used for signing macOS applications, including ChatGPT Desktop, Codex, Codex-cli, and Atlas. This certificate helps customers know that software comes from the legitimate developer, OpenAI.
Our analysis of the incident concluded that the signing certificate present in this workflow was likely not successfully exfiltrated by the malicious payload due to the timing of the payload execution, certificate injection into the job, sequencing of the job itself, and other mitigating factors. Nevertheless, out of an abundance of caution we are treating the certificate as compromised, and are revoking and rotating it.
Effective May 8, 2026, older versions of our macOS desktop apps will no longer receive updates or support, and may not be functional. These versions represent the earliest releases signed with our updated certificate:
As part of our investigation and response, we engaged a third-party digital forensics and incident response firm, rotated our macOS code signing certificate, published new builds of all relevant macOS products with the new certificate, and are working with Apple to ensure software signed with the previous certificate cannot be newly notarized. We have also reviewed all notarization of software using our previous certificate to confirm no unexpected software notarization occurred with these keys, and validated that our published software did not have unauthorized modifications. At this time, we have found no evidence of compromise or risk to existing software installations.
In the event that the certificate was successfully compromised by a malicious actor, they could use it to sign their own code, making it appear as legitimate OpenAI software. We have stopped new software notarizations using the old certificate, so new software signed with the old certificate by an unauthorized third party would be blocked by default by macOS security protections unless a user explicitly bypasses them. Once we fully revoke our certificate on May 8th, 2026, new downloads and launches of apps signed with the previous certificate will be blocked by macOS security protections.
The root cause of this incident was a misconfiguration in the GitHub Actions workflow, which we have addressed. Specifically, the action in question used a floating tag, as opposed to a specific commit hash, and did not have a configured minimumReleaseAge for new packages.
Were OpenAI products or user data compromised?
No. We have found no evidence that OpenAI products or user data were compromised or exposed.
Have you seen malware signed as OpenAI?
No. We have found no evidence that the potentially exposed notarization and code signing material have been misused, and we have confirmed all notarization events with the impacted material were expected.
Do I need to change my password?
No. Passwords and OpenAI API keys were not affected.
Does this affect iOS, Android, Linux, or Windows?
No. This only affects OpenAI macOS apps. This does not affect the web versions of our software.
Why are you asking me to update my Mac apps?
OpenAI identified exposure in a GitHub Actions workflow involved in the macOS app-signing process. Because the exposed workflow was related to macOS app signing, we are proactively rotating the notarization and code signing material used for OpenAI macOS applications. Updating ensures you are running versions signed with our latest certificate. This certificate helps customers know that software comes from the legitimate developer, OpenAI.
Where do I download the updated macOS apps?
Only download OpenAI apps from in-app updates or the official webpages below:
Do not install apps from links in emails, messages, ads, or third-party download sites. Be cautious of unexpected “OpenAI,” “ChatGPT,” or “Codex” installers sent through email, text, chat messages, ads, file-sharing links, or third-party download sites.
What happens after May 8, 2026?
Effective May 8, 2026, older versions of our macOS desktop apps will no longer receive updates or support, and may not be functional. These versions represent the earliest releases signed with our updated certificate:
Why are you not revoking the certificate immediately?
We have worked to block any further notarization of macOS apps with the impacted notarization material. This means that any fraudulent app posing as an OpenAI app using the impacted certificate will lack notarization, and therefore will be blocked by default by macOS security protections unless a user explicitly bypasses those protections.
Because new notarization with the previous certificate is blocked, and because the revocation may cause macOS to block new downloads and first-time launches of apps signed with the previous certificate, we are giving our users a 30-day window to update to minimize disruption. This window will help minimize user risk and allow impacted clients to update through built-in update mechanisms, ensuring they are appropriately remediated.
We are working with our partners to monitor for any indicators of misuse of the signing certificate, and will accelerate the revocation timeline if we identify malicious activity during this window.