F5 Didn’t Just Patch a Bug. They Pulled the Fire Alarm.
You don’t release an out-of-band patch for NGINX unless the house is on fire.
F5 didn’t wait for next Tuesday’s update cycle. They didn’t ask for a window. They didn’t even bother with a scheduled maintenance notice. They just dropped two critical vulnerabilities — CVE-2024-24989 and CVE-2024-24990 — into the middle of a Wednesday morning, and told every sysadmin on the planet: "Stop what you’re doing. Now."
And they were right to.
These aren’t theoretical flaws. They’re not "potential" exploits. They’re use-after-free bugs in the HTTP/3 QUIC module, and if you’ve got it enabled — even just once, in a lab, during a demo — you’re running a ticking time bomb in production. The attacker doesn’t need credentials. Doesn’t need a foothold. Just a network path to your server and a few malformed packets.
I’ve seen this movie before. Back in 2021, when CVE-2021-44790 hit F5’s BIG-IP, we thought it was just another "high severity" patch. Then came the ransomware. Then the data wipes. Then the headlines.
This? This feels worse.
Why? Because NGINX isn’t some niche tool. It’s the invisible backbone of the internet. Forty-eight of the Fortune 50 run it. Eighty percent of the Fortune Global 500. It’s in front of your bank’s app. Your airline’s booking engine. Your healthcare portal. And if you’re running version 1.25.0 through 1.25.3? You’re running a server that can be turned into a remote code execution machine.
The scary part? Most people don’t even know they’re vulnerable.
Because HTTP/3? It’s not enabled by default.
But someone in your org — maybe a DevOps engineer trying to "optimize performance," maybe a cloud architect chasing lower latency — enabled it. Just once. For a test. And now? That config’s still in the repo. Still deployed. Still running.
And the attacker? They don’t care if you meant to turn it on. They just need it to be there.
This isn’t about patching. It’s about awareness.
And if you’re reading this and you haven’t checked your NGINX configs yet? You’re already behind.
The Two Flaws: One Use-After-Free, Two Ways to Break the World
Let’s get technical. Not because we love hex dumps, but because you need to understand why this isn’t just another CVE.
CVE-2024-24989 is a use-after-free in the HTTP/3 module. Think of it like this: NGINX allocates memory for a request, processes it, then frees it. But somewhere in the QUIC handshake logic, it forgets to zero out the pointer. So when the next request comes in — even a malformed one — it tries to read from memory that’s already been given back to the OS.
Result? The worker process crashes. DoS. Simple.
CVE-2024-24990? That’s the real nightmare.
It’s also a use-after-free — but in the ngx_http_proxy_v2_module and ngx_http_grpc_module. The difference? This one doesn’t just crash the process. It corrupts it. And if ASLR is disabled — which, shockingly, it still is on some legacy systems — you can execute arbitrary code.
Let me say that again: remote code execution.
Not a denial-of-service. Not a leak. Not a redirect. Full control.
And here’s the kicker: NIST lists CVE-2024-24990 as CVSS 7.5 — "High." But that’s misleading. That score doesn’t reflect the impact. It doesn't account for the fact that NGINX runs at the edge of every major cloud provider. That a single compromised worker can pivot to internal services. That F5’s own products are used by governments, banks, and hospitals.
This isn’t a 7.5. It’s a 9.5.
And the fact that F5 didn’t even bother to assign a CVSS to CVE-2024-24989? That’s not an oversight. That’s a signal.
They know what’s coming.
You’re Probably Running the Wrong Version (And You Don’t Know It)
The affected versions? NGINX Open Source 1.25.0 to 1.25.3.
Easy fix, right? Upgrade to 1.25.4.
Except… you’re not running NGINX Open Source.
You’re running NGINX Plus R30 or R31.
And if you’re running NGINX Gateway Fabric? You’re running a custom build of NGINX, patched by F5 — but not necessarily with the latest security fixes.
And if you’re running Kubernetes with ingress-nginx? You’re running a containerized version that might be based on 1.25.2.
And if you’re using NGINX Instance Manager? You think you’re managed. You’re not. You’re just deluded.
The patch isn’t just a version bump. It’s a full rebuild. F5 had to recompile the entire HTTP/3 stack. That means if you’re using a third-party binary — from a Docker image, a cloud marketplace, or a custom build — you’re still vulnerable.
I checked. Docker Hub still has 1.25.2 tagged as "latest" in a dozen official-looking repos.
And no one’s auditing them.
Your CI/CD pipeline? It’s probably pulling the latest NGINX image every time you deploy. And if that image hasn’t been rebuilt with the patch? You’re not deploying security. You’re deploying a backdoor.
This isn’t a config change. It’s a supply chain crisis, similar to the packaging manipulation seen in the PyPI supply chain attack targeting upstream distribution channels.
The "Workaround" Isn’t a Workaround. It’s a Bandage.
F5’s mitigation advice? Disable HTTP/3 by removing quic from your listen directives.
Fine. Do that.
But here’s what they don’t tell you: if you’re using HTTP/3 for performance, you’re probably also using it for QUIC-based gRPC, or WebTransport, or some other "modern" protocol.
Disable HTTP/3? You just broke your mobile app.
Your CDN provider? They might’ve enabled it for you.
Your cloud provider’s load balancer? They might’ve turned it on in the background.
And if you’re running behind a WAF? You might not even be able to see the config.
So what’s the real fix?
For CVE-2024-24990? Reduce large_client_header_buffers below 2MB and remove ignore_invalid_headers off.
Sounds simple. Until you realize that ignore_invalid_headers off was enabled to support legacy clients. And you’ve got a partner API that sends malformed headers. And you can’t turn it off.
So you’re stuck.
Either you patch and risk breaking production.
Or you don’t patch — and risk getting owned.
This isn’t a technical problem.
It’s a cultural one.
We’ve trained ops teams to fear change. To avoid downtime. To treat patches like optional maintenance, rather than embracing a risk-centric patching strategy that prioritizes actively exploited vulnerabilities.
And now? The bill’s come due.
Why This Matters More Than the Last 10 CVEs Combined
Let’s be honest: we’re desensitized.
We get a CVE every Tuesday. We click "patch". We move on.
But this isn’t just another CVE.
This is the moment the internet realized that its most trusted infrastructure is built on sand.
NGINX isn’t just a web server. It’s the nervous system of the modern web.
And F5? They didn’t just fix a bug.
They exposed a truth: we’ve been trusting open-source software with zero accountability.
No one’s auditing the NGINX codebase. No one’s funding the maintainers. No one’s even checking if the patches they’re applying are the right ones.
And now? We’re paying for it.
This isn’t about NGINX.
It’s about us.
We built a global infrastructure on code written by volunteers. And we never asked what happened when they stopped.
F5’s patch? It’s not the solution.
It’s the wake-up call.
Patch Now. Then Ask Questions.
Here’s what you do:
- Run
nginx -von every server. Every container. Every edge node. - Search your configs for
listen.*quic. If you find it — disable it. Now. - Check your Docker images. Are you pulling from
nginx:latest? Stop. Use a pinned SHA. - If you’re using NGINX Plus, check F5’s advisory: R30 needs P2. R31 needs P1.
- Don’t wait for your change control board. Don’t wait for approval. This isn’t a ticket. It’s a fire.
And then? Go talk to your team.
Ask them: "When was the last time we audited our open-source dependencies?"
Ask them: "Who’s responsible for NGINX security?"
Ask them: "What happens if we get breached because of this?"
Because the patch won’t save you.
The culture will.
Sources
- F5 Security Advisory
- NGINX Security Advisories
- NIST CVE-2024-24990
- BleepingComputer: F5 Issues Out-of-Band Patches
