300 Million Companies Extract From Open Source. Only 4,200 Pay. Your Cluster Has the CVE.

On March 24, 2026, a GitHub repository quietly went read-only.

No press release. No postmortem. Just a bot archiving the code and a Kubernetes Steering Committee statement most engineers didn't read until their migration deadline had already passed.

The repository was kubernetes/ingress-nginx.

It was routing traffic for about half of all Kubernetes clusters on Earth. And it stopped receiving security patches. Forever.

Here's what every migration guide left out.

This wasn't a technical sunset. The codebase wasn't obsolete. There was no production-ready replacement waiting in the wings. It died because two people burned out. And the trillion-dollar industry running on their work didn't notice until it was already over.

The Math Nobody Put Together Until Now

Let me put four numbers on the table and let them sit for a second.

$8.8 trillion. That's the demand-side value of open source software — from a 2024 Harvard Business School study by Hoffmann, Nagle, and Zhou. It's what corporations worldwide would need to spend to rebuild every OSS dependency if it disappeared tomorrow.

$4.15 billion. That's the supply-side value. What it would actually cost to create that software from scratch today.

The gap between those two numbers is the largest economic arbitrage in the history of software. Corporations extract 2,000x their "investment" in OSS every single year.

But we're not done.

300 million. Commercial entities globally consuming open source software — cited at FOSDEM 2026.

4,200. The number financially participating in GitHub Sponsors and similar mechanisms.

Do the math yourself.

That's a 99.999% freeloading rate. Not a metaphor. Actual arithmetic.

And here's what Tidelift found in their 2024 State of the Open Source Maintainer Report: 60% of maintainers are unpaid. 60% have quit or seriously considered it. 44% report severe burnout — and that number hasn't moved in three years.

The 1–2 People Who Actually Kept Half the Internet Running

Before we get to CVEs and migration playbooks, you should know who was actually doing this work.

The NGINX.org blog — run by F5, who eventually forked the project into a commercially supported version — described it plainly in November 2025:

Nights and weekends.

For a project routing traffic through about half of all cloud-native environments on Earth — confirmed by the Kubernetes Steering Committee — serving billions of requests a day across data centers, bare-metal servers, and home labs.

Why It Was Already Structurally Unfixable

Here's the architectural reality every migration guide skipped.

Ingress NGINX's killer feature — the reason it dominated the space — was also its fatal flaw. It let users inject NGINX directives directly through annotation fields.

Hundreds of annotations. Deeply embedded in every enterprise deployment.

Every annotation was a potential attack surface. Two part-time maintainers couldn't keep up. Not because they weren't skilled — because no two humans in their spare time can security-audit infrastructure 300,000+ clusters depend on.

The Kubernetes Steering Committee said it directly:

That's not a deprecation notice. That's a burnout confession.

And it wasn't just ingress-nginx. The External Secrets Operator — used by thousands of enterprise K8s deployments — posted an emergency statement in August 2025: "A very small team of maintainers is responsible for everything… this situation is unsustainable." They halted SemVer releases.

The thing powering trillion-dollar companies is quietly going dark. One maintainer at a time.

The Quietest Failure Mode of All

And then there's the third way this goes wrong.

In 2022, a new contributor named Jia Tan started submitting legitimate patches to XZ Utils — a compression library bundled inside virtually every Linux distribution. Two years of real commits. A built reputation. Until March 2024.

CVE-2024-3094. CVSS 10.0.

A backdoor that would have given remote code execution access to hundreds of millions of servers via OpenSSH.

Not caught by a security team. Caught because a Microsoft engineer noticed a 500ms SSH delay.

We got lucky. Once.

The Kubernetes SIG retired ingress-nginx before the pattern could repeat. When maintainers are gone and the codebase is an open attack surface — retirement is the responsible call.

CVE-2025-1974. CVSS 9.8. The Last Patch They'll Ever Write.

Now we get to the part that should make every platform engineer uncomfortable.

Wiz security researchers disclosed IngressNightmare on March 24, 2025 — exactly one year before the repo went dark.

Four related vulnerabilities, all building toward one:

CVE-2025-24513 · CVE-2025-24514
CVE-2025-1097  · CVE-2025-1098

All building toward one: CVE-2025-1974. Unauthenticated Remote Code Execution. CVSS 9.8.

One Annotation. Zero Auth. Your Entire Cluster.

The admission webhook was the attack surface.

Its job: intercept every Ingress CREATE and UPDATE, validate the NGINX config it would generate, reject invalid ones. Every ingress-nginx install shipped with it.

Here's the distinction nobody explained. CVEs 1–4 require the attacker to already have permission to create Ingress objects — a fairly privileged cluster action.

CVE-2025-1974 removes that requirement entirely.

The webhook runs at a fixed internal address — https://ingress-nginx-controller-admission.ingress-nginx.svc.cluster.local — reachable from any pod by default. No authentication. No TLS client cert. Nothing.

An attacker on the pod network skips kubectl completely. They craft an AdmissionReview JSON body with a malicious annotation and POST it directly to that URL. The Kubernetes API server never touches this request.

The webhook calls nginx -t on the injected config. An ssl_engine directive loads a shared library the attacker uploaded via NGINX's client body buffer. Arbitrary code executes inside the ingress-nginx pod.

(Wiz Research documented the full four-step exploit chain. The above is the short version.)

Confirm your admission webhook with this — run it now:

kubectl get ValidatingWebhookConfiguration \
  ingress-nginx-admission -o yaml

Here's what makes it catastrophic.

By design, ingress-nginx has access to all Secrets cluster-wide — so it can read TLS certs across namespaces. That's not a bug. It's an architectural necessity.

But it means: one crafted POST, no credentials, full cluster takeover.

The official Kubernetes Security Response Committee blog was blunt:

Translation: if any developer on your squad can run kubectl apply -f ingress.yaml — they're an attack vector. And so is every other workload sharing your VPC.

CVE-2025-1974 was patched in v1.11.5 and v1.12.1.

That was the last security patch ingress-nginx will ever receive. The next vulnerability in this class drops into a read-only repository. No one's home.

You Want to Know What It Looks Like When a Corporation Actually Funds a Project?

In March 2025, Microsoft announced tsgo — a port of the TypeScript compiler rewritten in Go, eliminating the Node.js runtime entirely.

Real numbers, from real codebases:

A dedicated team. Months of senior engineering time. All to shave 70 seconds off a local build. Because it improved developer velocity.

Now hold that thought.

The same industry — the one that funds compiler speedups for developer convenience — left 1–2 volunteer engineers maintaining the network gateway securing about half of the world's containerized traffic. For years. In their spare time.

That's not hypocrisy. That's a resource allocation policy. And the policy says: developer velocity is worth millions. Network security for half the internet is worth nothing.

Run This. Right Now. Before You Finish Reading.

Open a terminal.

I mean it. The rest of this article will be here when you get back.

# Step 1: Find any running ingress-nginx controller pods
kubectl get pods --all-namespaces \
  -l app.kubernetes.io/name=ingress-nginx

# Fallback for pre-0.43 Helm chart installs:
kubectl get pods --all-namespaces | grep ingress-nginx

# Step 2: Check the admission webhook is registered
kubectl get ValidatingWebhookConfiguration \
  ingress-nginx-admission 2>/dev/null \
  && echo "⚠️  Webhook registered — check your version."

# Step 3: Check for active Ingress resources
kubectl get ingress -A

If any command returns results: you're running permanently unpatched, read-only infrastructure. Right now.

That's not a migration task for next sprint. That's a live exposure window.

Running AKS Application Routing or managed GKE? You've got a grace period, not a pass. Microsoft's extended support runs out in November 2026. Nothing beyond that date.

Multi-Cluster Sweep

Running more than one cluster? Don't check just one context.

# Multi-cluster sweep — every context in your kubeconfig
for ctx in $(kubectl config get-contexts -o name); do
  echo "── Context: $ctx ──"
  kubectl --context="$ctx" get pods --all-namespaces \
    -l app.kubernetes.io/name=ingress-nginx 2>/dev/null
done

One more thing. The official CVE nuclei template uses the Shodan query ssl:"ingress-nginx" port:8443 to find clusters with an internet-exposed admission webhook. If your endpoint appears there — that's your P0 for today.

4 Questions. 15 Minutes. Your Dependency Tree, Exposed.

Don't stop at ingress-nginx. Run this on your top 5 OSS dependencies. Four questions each. Fifteen minutes total.

1. Contributor count trend. Open GitHub Insights. Is active contributor count growing or collapsing? 20 contributors dropping to 4 in 18 months is a yellow flag. Six months later, it's red.

2. Average issue response time. Are critical bugs answered in days or months? Widening response time is the leading indicator of maintainer burnout — before anyone posts anything publicly.

3. Named corporate sponsorship. Check the GitHub Sponsors page. Is any org paying for sustained engineering time? Not $50 donations. Real sustained funding.

4. Last release vs. last open CVE. Is the gap between the most recent patch and the oldest open security issue widening? That gap is your unhedged exposure window.

The Minimum Bar Is Not Zero

I'm not asking your company to become the Linux Foundation.

I'm asking you to stop being one of the 299,999,800.

What One Company Actually Did

Sentry — a 129-person engineering team — distributed $750,000 to open source maintainers in 2024. That's $5,813 per developer on their payroll.

They used thanks.dev and the Open Source Collective to algorithmically distribute based on actual usage — no manual dependency tree review needed.

$30,000 to Django. $16,500 to Python. $15,000 to Rust. Hundreds of smaller distributions to the invisible packages nobody thinks about until they post "we need help" on Reddit.

Here's what kills the "we can't afford it" argument:

When your company doesn't fund its dependencies, it's not being neutral. It's choosing a worse security posture. On purpose.

Your Action List for This Week

1. Run the cluster audit. The kubectl commands above. Two minutes.
2. Run the 4-question health check. Top 5 OSS dependencies. Fifteen minutes.
3. Open one GitHub Sponsors page. Find the most critical, least-funded project you depend on. $5/month ends the streak of zero.
4. Open one PR. A documentation fix counts. A failing test counts. A README typo counts. Not zero.
5. Forward this to your CTO. Not as a guilt trip. As a risk briefing.

The Open Source Pledge sets the minimum bar at $2,000 per year per full-time developer. At 50 engineers, that's $100K/year. Less than one junior engineer's salary. Less than a month of your Datadog bill.

The emergency migration, under a live CVE, with 160 ingresses and a four-month deadline — that one costs real money. The GitHub Sponsors subscription is $5 a month.

The next ingress-nginx is already burning out somewhere in your dependency tree.

You just don't know which one it is yet.

Run the audit. Find out.