The NGINX Rift: An 18-Year-Old Bug and an Abandoned Ingress Controller

The bomb that went off on a quiet Friday afternoon

On May 13, a vulnerability called CVE-2026-42945 went public. Someone named it NGINX Rift. CVSS 9.2, critical. But if you run this stuff for a living, the score wasn't the part that made your stomach drop. It was that there was nowhere to get a patch.

The Kubernetes project retired ingress-nginx six months earlier, in March 2026. The repo was archived, read-only. No more patches, ever. And that's exactly when an 18-year-old bug crawled out into the daylight.

Vulnerabilities themselves are routine. There's a new CVE somewhere every week. Normally you bump to the patched version, validate with a canary, done. This time the last box in that pipeline — the thing that actually supplies the patch — was gone. That's the whole story.

A heap buffer overflow that sat there for 18 years

NGINX Rift has been in the code since NGINX 0.6.27 shipped in 2008. It's a heap buffer overflow in ngx_http_rewrite_module, and for nearly two decades nobody spotted it.

Here's how it works. The NGINX rewrite engine runs in two passes. The first pass computes how much memory it needs; the second writes the actual data. The catch is that the two passes can arrive at different lengths.

When a rewrite directive's replacement string contains a question mark and a capture backreference gets expanded, the length math drifts. Characters like +, %, and & get URL-encoded and swell from one byte to three. The allocation was sized for one byte. So you end up writing past the end of the buffer.

The worker process goes down, and on systems with ASLR disabled you can get remote code execution. On modern systems the realistic risk is persistent denial of service rather than RCE. But an ingress going down means your entry point for external traffic is gone. Don't wave that off as "just DoS."

The patch exists. There's nowhere to get it.

The ironic part is that the fix itself is trivial. Upstream NGINX shipped it the same day in 1.30.1 and 1.31.0. NGINX Plus got patched builds too.

Go look at kubernetes/ingress-nginx and the last release is v1.15.1. The vulnerable code is right there, and there won't be another version.

Separate cause from effect and the picture gets clear. Cause: volunteers maintained this project for years while the vendors making money off the controller contributed nothing. The maintainers burned out and left. The project shut down. Effect: those same vendors now sell you the patch.

That's the open source trap. Infrastructure that looked free turns into an invoice the moment the people holding it up walk away.

HeroDevs and the commercial answer

HeroDevs announced "NES (Never Ending Support)" in April, one month after the project wound down. It's a commercial fork built on ingress-nginx v1.15.1.

They moved fast on CVE-2026-42945: pulled the upstream NGINX 1.30.1 fix, applied it to their ingress-nginx build, and shipped a VEX document so CVE scanners register it as resolved.

Time for an open source maintainer to do the same work: zero hours. There is no open source maintainer.

Pricing isn't published — just "contact sales." HeroDevs runs this business model across AngularJS, Node.js, .NET, Spring, and other EOL projects: paid support forever. Honestly, it's hard to be mad about it. Somebody has to read that C code, and their hours have a price tag. The point is that we're the ones now looking at the price tag.

What this does to a real production environment

Regulated industries have it worse. Take a hospital patient monitoring system under FDA rules — running EOL software in the L7 data path is an automatic finding in SOC 2.

Same for PCI-DSS, ISO 27001, HIPAA. FDA Class II devices and EU MDR Class IIa are stricter still: known vulnerabilities have to be in the cybersecurity risk file, and CVE-2026-42945 is now an official vulnerability in every ingress-nginx 1.15.1 deployment on earth.

I've sat through a lot of audits in financial IT. Auditors do not count "we'll wait and see what the community does" as a plan. They look at exactly one thing: is there a documented, actionable remediation plan, with dates and an owner on it. "We'll apply the patch when upstream ships one" is a blank line now that upstream is gone.

Four realistic paths. HeroDevs NES costs money but buys you audit defensibility. Migrating to the Gateway API is a multi-week engineering project. You can swap the ingress controller outright for Traefik, F5's commercial build, HAProxy, or Cilium Gateway. And if you're bleeding right now, a frontend WAF — Cloudflare, Akamai, AWS WAF — gets you temporary mitigation today.

If I had to sequence it: WAF in the short term to stop the bleeding, then move to the Gateway API or another controller over the medium term. NES is the bridge you stand on in between, not the destination.

This isn't an exception, it's the pattern

The last few years keep replaying this. Redis changed its license in 2024 and the community forked Valkey. Elasticsearch did the same thing in 2021 and AWS carved out OpenSearch. Terraform's 2023 license change produced OpenTofu. MongoDB adopted the SSPL in 2018 to fence off cloud managed services.

Ingress NGINX got there by a different mechanism, same destination. The community burned out and left, and infrastructure running half the cloud native world became your problem one morning.

The individual incidents matter less than the pattern. Critical open source projects have no institutional immune system. In a company, someone quits and a replacement arrives, handover happens, ownership transfers. A volunteer project just stops when that person burns out. And the cost lands on the users.

Figuring out if you're affected

Not every Kubernetes environment is exposed. Before you panic, go check your own cluster.

Start with what's clear. The AWS Load Balancer Controller is unaffected — ALB doesn't use NGINX. Same for putting AWS API Gateway in front of EKS. If you're on Istio, Traefik, HAProxy, Contour, or Cilium Gateway, this one is somebody else's problem. If you're running kubernetes/ingress-nginx v1.15.1, you're squarely in it. F5's commercial NGINX Ingress Controller has affected versions too, but those already have patches out.

The problem, per Datadog's research, is that roughly 50% of cloud native environments still run ingress-nginx. The Kubernetes steering committee announced the retirement five months ago and most teams still haven't finished migrating. That's not surprising. There's usually no reason to touch an ingress that works. A deprecation notice lands, nothing turns red, and it slides down the priority list. Then a CVE like this drags the entire backlog to the top in one shot.

The thing I'm actually worried about is the next CVE

CVE-2026-42945 will be mostly handled within six weeks. It's the next one that bothers me.

The NGINX rewrite module is now an abandoned C codebase sitting across half the world's cloud native deployments. The May 2026 release alone turned up four more memory corruption bugs in that same source file, plus a fifth tracked as CVE-2026-9256.

There will be a sixth. There will be a seventh. Nineteen years of C with nobody left tending it — why would the bugs stop there?

It all lands in the same place. Open source infrastructure was never free. Someone was always paying, and until now that someone was volunteers paying in time. That time ran out, and the invoice came to us. If you've been budgeting infrastructure by license fees and instance hours, it's time to add a line for who's on the hook for this thing long-term.