Blog Incident Analysis April 8, 2025 5 min read

The Kubernetes Component Built to Validate Changes Was the Way In. 43% of Cloud Environments Were Exposed.

Wiz's IngressNightmare disclosure: four CVEs in ingress-nginx, the worst a 9.8-critical unauthenticated RCE in the admission controller - the very component that validates changes before they enter the cluster.

By the AuthorityGate Architect Team

On March 24, Wiz Research and the Kubernetes Security Response Committee coordinated the disclosure of IngressNightmare: four vulnerabilities in ingress-nginx, one of the most widely deployed ingress controllers in Kubernetes. The worst of them, CVE-2025-1974, is rated CVSS 9.8 Critical - unauthenticated remote code execution. The other three (CVE-2025-1097, CVE-2025-1098, CVE-2025-24514) compound it. But the detail that should stop every platform team cold is not the score. It is where the hole lives.

"Ingress NGINX deploys an admission controller within its pod, designed to validate incoming ingress objects before they are deployed." - Wiz Research

Read that again. The vulnerable component is the admission controller - the validating webhook whose entire job is to inspect changes before they are allowed into the cluster. The gatekeeper was the way in.

How the gatekeeper became the hole

The attack is uncomfortably simple. An attacker sends a malicious ingress object to the validating webhook, which by default is reachable over the network without authentication. During config validation - the safety check itself - the injected NGINX configuration executes code inside the controller pod. And that pod is no ordinary workload: exploitation grants access to all Secrets stored across all namespaces, which Wiz assesses can lead to complete cluster takeover. The component trusted to say no to bad changes held the keys to everything.

The exposure numbers are worse than the mechanism. Wiz found that about 43 percent of cloud environments are vulnerable, and over 6,500 clusters - including Fortune 500 companies - exposed vulnerable admission controllers directly to the public internet, where anyone could reach them.

Nearly half the cloud was exposed through its own validator Share of cloud environments vulnerable to IngressNightmare, per Wiz Research
0% of cloud environments run a vulnerable ingress-nginx admission controller
0%50%100%

6,500+ clusters exposed the admission controller directly to the public internet, Fortune 500 companies among them.

The blast radius grows every year

This lands on an industry that just went all in. The CNCF's Cloud Native 2024 survey, announced April 1, found Kubernetes production use hit 80 percent in 2024, up from 66 percent the year before. Every point of that curve is another fleet of clusters whose change pipeline runs through components like this one.

Kubernetes in production keeps climbing Share of organizations using Kubernetes in production, CNCF annual survey
0%
2023
0%
2024
A massive open vault door standing alone in a dark corridor with light pouring through the unguarded opening
The checkpoint everyone trusted was the one entrance nobody was watching.

You do not need an attacker to learn this lesson

IngressNightmare is the malicious version of a failure mode the industry already knows from the non-malicious side. Reddit's own postmortem of its March 2023 Pi-Day outage describes a routine Kubernetes 1.23-to-1.24 upgrade that removed the deprecated node-role.kubernetes.io/master label. Their Calico route reflectors selected on exactly that label, so cluster networking collapsed. Reddit was down for 314 minutes. The route-reflector configuration was documented nowhere, and recovery required a risky restore from backup. No exploit, no adversary - just a consequential change that no independent gate examined before it took effect.

Put the two incidents side by side and the pattern is the same: the change pipeline had one layer of trust, and when that layer failed - by compromise in one case, by blind spot in the other - nothing else stood between the change and production.

The AuthorityGate take

The wrong lesson from IngressNightmare is that validation is futile. The right lesson is that validation has to be built the way you build anything you cannot afford to lose: layered, least-privileged, and independent of the workload it guards. The ingress-nginx admission controller was a single privileged webhook running inside the very pod it was protecting, holding read access to every Secret in the cluster. That is not a gate. That is a single point of failure with a badge.

This is why change validation in Keystone is a pipeline of gates, not one checkpoint - and why the consequential decisions route to a named human instead of terminating in an automated yes. A validator that can be compromised, or simply be wrong, should never be the only thing between a change and your production environment. Independence is the property that makes a gate worth trusting.

The fixes shipped the day of disclosure: ingress-nginx v1.12.1 and v1.11.5, released March 24. If you have not patched, patch now, and check whether your admission webhook is reachable from anywhere it should not be. Then ask the harder question: if your gatekeeper failed tomorrow - hacked or just mistaken - what else would catch the change?

Share this post: LinkedIn

Go deeper

Every agent action, validated before it takes effect

AuthorityGate's newsletter breaks down real AI incidents and the governance failures behind them. Our configurable 8-gate validation model is how organizations keep a named human accountable for what their AI actually does.