IngressNightmare shows how Kubernetes identity trust can collapse

At a glance

What this is: This analysis explains how the IngressNightmare vulnerabilities in ingress-nginx can turn configuration injection and admission-controller RCE into privileged cluster access and lateral movement.

Why it matters: It matters because Kubernetes teams have to govern workload identity, admission control, and secret access as one trust boundary, not as isolated technical tasks.

Context

IngressNightmare is a set of Kubernetes ingress-nginx vulnerabilities that can be chained into a higher-impact compromise. The key issue is not just code execution, but what that execution can reach once it runs inside a controller that sits close to cluster traffic and identity trust.

CrowdStrike's analysis shows that the admission controller context matters because it runs with a service account that can access cluster secrets and cluster network resources. That makes the vulnerability a workload identity and governance problem as much as a patching problem.

The article's operational focus is typical for Kubernetes environments that rely on ingress controllers as shared infrastructure. When controller privilege is broad and admission paths are exposed, a small input flaw can become cluster-wide trust collapse.

Key questions

Q: What breaks when an ingress controller can be reached through unsanitized annotations?

A: The controller stops being a passive traffic gate and becomes a runtime injection surface. In Kubernetes, that matters because configuration fields can be converted into executable behaviour before any deeper exploit runs. Once the controller is writable through untrusted inputs, the trust boundary between external traffic and internal cluster control weakens immediately.

Q: Why does admission-controller RCE create higher risk than a normal container escape?

A: Because the code runs inside a controller identity that already carries delegated access to secrets and the cluster network. The attacker is not just breaking out of a pod, they are inheriting the privileges of a platform component. That changes a local exploit into a path toward cluster-wide identity abuse.

Q: What are the signs that a Kubernetes ingress controller has become a lateral-movement path?

A: Look for secret enumeration, unexpected access to cluster-wide resources, and internal traffic from the controller process toward other workloads. Those signals show the controller is being used as an identity bridge rather than only as an ingress function. A widened secret scope is often the first practical warning that the blast radius is too large.

Q: How should security teams reduce Kubernetes controller blast radius?

A: Start by treating ingress and admission controllers as privileged non-human identities. Remove cluster-wide secret access, limit network reach, and separate duties so one controller cannot both admit workloads and enumerate sensitive objects. Then pair those changes with version inventory and runtime detections, because blast radius is reduced by privilege design plus visibility, not by patching alone.

Technical breakdown

How ingress-nginx annotation injection becomes a control-plane foothold

IngressNightmare begins with configuration injection through unsanitized ingress annotations such as auth-url, auth-tls-match-cn, and mirror settings. Those annotations are not just metadata, because ingress-nginx converts them into runtime configuration that affects how traffic is handled. If an attacker can influence the generated configuration, they can shape controller behaviour before any deeper exploit runs. In Kubernetes, that matters because the ingress layer often sits at a trust boundary between external requests and internal services. Once that boundary is writable by untrusted input, the controller becomes an entry point rather than a guardrail.

Practical implication: review which controller inputs are effectively executable trust decisions, not harmless configuration fields.

Why admission-controller RCE turns a bug into identity abuse

The second stage is CVE-2025-1974, an admission-controller remote code execution flaw that allows arbitrary file upload and execution in the ingress-nginx process context. That process runs under a service account with privileged access to cluster secrets and cluster network access, which changes the impact entirely. Remote code execution alone is bad, but RCE inside a highly authorised controller gives the attacker the same reach that the controller has been granted. This is the classic workload identity failure mode: the compromise is not just code, it is delegated trust.

Practical implication: treat controller service accounts as high-value identities and scope them to the minimum secret and network access required.

How cluster secrets and network reach enable lateral movement

Once code runs with the controller's identity, the attacker can query secrets and pivot across cluster components. CrowdStrike notes that the attacker could use the service account to retrieve cluster secrets and then move laterally within the cluster network. This is the point where a local controller issue becomes a broader Kubernetes compromise, because secrets often unlock additional workloads, namespaces, and integrations. The architectural lesson is that secret access and network reach must be evaluated together, since either one can widen the blast radius after initial compromise.

Practical implication: map secret access paths and lateral movement paths together when assessing ingress controller exposure.

Threat narrative

Attacker objective: The objective is to turn a single ingress controller flaw into privileged cluster access, secret exposure, and broader control of the Kubernetes environment.

1. Entry occurs when an attacker exploits unsanitized ingress annotations to inject configuration into ingress-nginx.
2. Escalation follows when CVE-2025-1974 enables remote code execution inside the admission controller process.
3. Impact occurs when the compromised service account is used to query cluster secrets and move laterally through the Kubernetes environment.

Breaches seen in the wild

• Schneider Electric Jira breach 2024: Credentials linked to a Lumma infostealer infection gave Hellcat access to Schneider Electric's Jira; 40GB and 400,000 user rows claimed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Kubernetes identity trust collapses when controller privilege is treated as infrastructure plumbing rather than governed access. Ingress controllers are often deployed as shared platform components, but they still run under service accounts with real authorization. When those identities can read secrets and reach internal networks, an exploit against the controller becomes an identity event, not just an application bug. Practitioners need to stop separating control-plane hardening from identity governance.

IngressNightmare is a workload identity problem, not only a vulnerability-management problem. The article makes clear that the attacker value comes from what the controller identity can already do once execution is gained. That means service-account scope, secret exposure, and network reach form one blast radius. The practical conclusion is that workload identity reviews must include the runtime privileges of shared Kubernetes components.

Admission control is part of the trust boundary, so its failure invalidates the trust model for the entire ingress path. Unsanitized annotations become dangerous because they influence controller behaviour before policy can reassert itself. CrowdStrike's analysis shows how quickly a single trust boundary can fail when user-controlled inputs are allowed to shape controller configuration. Practitioners should treat admission paths as enforcement surfaces, not passive middleware.

Identity blast radius is the right concept for this class of Kubernetes risk. A controller with broad secret access and cluster network reach creates an outsized compromise surface even when the initial bug is narrow. That is why patching alone is not enough as a governance response. The durable lesson is to shrink the blast radius of every identity embedded in the cluster control plane.

IngressNightmare validates the need to govern Kubernetes components as first-class identities. If a controller can authenticate, read secrets, and influence other workloads, it is an identity subject with lifecycle, privilege, and exposure decisions attached. That framing aligns with OWASP-NHI and workload-identity governance. The implication for practitioners is to inventory controllers as identities, not only as software objects.

From our research library:

• Kubernetes production adoption has surged from 66% in CNCF's 2023 survey to 82% in 2025.

What this signals

Identity blast radius: Kubernetes controllers should be measured by the amount of secret access and network reach their identities carry, because exploit impact follows delegated privilege. When a controller can reach cluster-wide secrets, the compromise surface is no longer local to the pod.

Ingress controllers are especially sensitive because they sit at the boundary between untrusted traffic and trusted runtime behaviour. That makes admission paths and service accounts part of one governance model, not separate engineering domains. Practitioners should inventory those identities as shared platform assets.

The practical shift is from patch-only thinking to trust-boundary thinking. If an ingress component can accept unsafe input, execute code, and use a privileged service account, the organization has a cluster trust problem that has to be governed as such.

For practitioners

• Patch affected ingress-nginx versions immediately Upgrade all affected clusters running v1.12.0, v1.11.0 through v1.11.4, and any version prior to v1.11.0 as soon as operationally possible.
• Remove or isolate the ValidatingWebhook as a stopgap If patching cannot happen immediately, remove the ValidatingWebhook or make it inaccessible from the public internet until a fixed version is deployed.
• Audit ingress controller service-account scope Review what secrets, namespaces, and network paths the ingress-nginx service account can reach, then reduce that scope to the minimum required for controller operation.
• Use exposure dashboards to find vulnerable controllers Track Linux hosts, Kubernetes clusters, and public cloud environments for ingress-nginx instances and compare observed versions against the vulnerable set.
• Detect secret-query activity in cluster logs Search for kubectl get secret commands and related post-exploitation behaviour so secret access attempts are visible as soon as they appear.

Key takeaways

• IngressNightmare shows how a narrow ingress-nginx flaw can become a broader Kubernetes trust collapse once controller privilege is exposed.
• The article ties the risk to privileged service-account access, cluster secrets, and lateral movement inside Kubernetes environments.
• Kubernetes teams should govern controller identities, admission boundaries, and secret scope together instead of treating them as separate tasks.

Key terms

• Ingress Controller: A Kubernetes component that manages how external traffic reaches services inside the cluster. Because it sits at the edge, an ingress controller is part of the exposure path, not just plumbing. If it inherits vulnerable proxy behaviour, the risk spreads to many workloads at once.
• Service Account: A special-purpose account used by applications, automated tools, or services rather than a human user to interact with systems, APIs, and infrastructure. Service accounts are a primary category of NHI and one of the most frequently exploited attack vectors.
• Admission Controller: An admission controller is a Kubernetes control that validates or changes workload requests before the cluster admits them. It acts as a deployment-time policy layer, which makes it useful for blocking unsafe images, rejecting risky configuration, and enforcing runtime standards that build-time scans may miss.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

Deepen your knowledge

Identity lifecycle management, secrets management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.