IngressNightmare shows how Kubernetes identity trust can collapse

At a glance

What this is: This is CrowdStrike Engineering’s analysis of the IngressNightmare Kubernetes vulnerabilities, which chain initial injection bugs into privileged execution and secret access.

Why it matters: It matters because Kubernetes controllers often sit on the boundary between runtime traffic and cluster-wide trust, so NHI and IAM teams need to treat them as identity-bearing control points.

By the numbers:

• CVE-2025-1974 has a CVSS score of 9.8 and allows arbitrary file upload and execution within the ingress-nginx process.
• All versions prior to v1.11.0, v1.11.0 to 1.11.4, and v1.12.0 are affected.

👉 Read CrowdStrike Engineering's analysis of IngressNightmare in Kubernetes

Context

IngressNightmare is a reminder that Kubernetes exposure is not only a software vulnerability problem. When an ingress controller or admission controller can influence cluster behaviour, it inherits identity-like authority, including access to secrets, workload context, and network pathways that can be abused once execution is achieved. For NHI governance, that makes controller hygiene part of the trust model, not a separate infrastructure task.

The article is relevant to practitioners because it shows how a single chain can move from public-facing input handling to privileged cluster access. That is a typical failure mode in modern cloud estates: runtime components accumulate trust faster than teams formally model it, then become the bridge between a vulnerability and non-human identity compromise.

Key questions

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.

Q: Why do Kubernetes workloads complicate zero trust architecture?

A: Kubernetes workloads complicate zero trust because runtime components often carry standing authority even when their input channels are exposed to the internet or to other pods. That means the trust decision is embedded in the workload identity itself, not just in the network path. Zero trust works only when those identities are least-privileged and continuously verified.

Q: What is the difference between patching a controller and governing its identity?

A: Patching removes a known exploit path, but governing identity determines how far an attacker can go if the component is compromised before or between patches. Identity governance covers service-account permissions, secret access, network reach, and telemetry. In practice, patching is a corrective control, while identity governance is the control that limits blast radius.

Q: When should teams treat a Kubernetes admission component as high risk?

A: Treat it as high risk whenever it can read secrets, mutate cluster objects, or run with network access that reaches sensitive workloads. Those capabilities make the component a valuable non-human identity, not a simple middleware service. If compromise of that component would expose secrets or lateral movement paths, it deserves privileged control treatment.

Technical breakdown

How ingress-nginx turns a web-facing bug into cluster-wide trust

Ingress controllers accept incoming traffic and often process annotations or configuration passed from Kubernetes objects. In the IngressNightmare chain, unsanitized annotations can be used for configuration injection, which means attacker-controlled input changes how the controller behaves. Once the controller accepts malicious configuration, the attack can pivot into the admission path, where code execution becomes possible. The important architectural point is that the controller is not a passive parser. It is a trust-enforcing component with real authority over routing, policy, and access to internal resources.

Practical implication: Treat ingress and admission components as privileged trust brokers and review every input path that can alter controller behaviour.

Why the admission controller matters for NHI and secret exposure

The admission controller in this case runs with a service account that can read cluster secrets and talk across the cluster network. That combination makes the workload identity far more dangerous than the original bug itself. In NHI terms, the service account is a standing identity attached to a component that may be reachable from attacker-controlled code after exploitation. This is a classic identity blast radius problem. The exploit does not need to steal a human password if the runtime identity already carries high-value access.

Practical implication: Reduce service-account privilege on controller pods and verify that no admission component has broad secret-read permissions by default.

Why patching alone is not enough in Kubernetes exposure cases

Patching closes the known exploit path, but it does not by itself answer whether the environment can detect abuse before compromise. The article’s monitoring guidance shows the operational need to see vulnerable versions, admission webhook exposure, and suspicious secret enumeration together. That is the governance lesson. A secure state depends on inventory, version control, runtime detection, and rapid remediation, not patching in isolation. For NHI practitioners, the question is whether the controller can still be abused if one compensating control fails.

Practical implication: Pair patching with version inventory, webhook exposure checks, and detections for secret enumeration and shared-object loading.

Threat narrative

Attacker objective: The attacker aims to turn a controller-side code execution bug into privileged Kubernetes access, secret harvesting, and broader cluster compromise.

1. Entry begins with configuration injection through vulnerable ingress-nginx annotations or admission paths that accept unsanitized input.
2. Escalation follows when the attacker reaches arbitrary file upload and code execution inside the admission controller process, which runs with a powerful service account.
3. Impact is cluster-wide secret access and lateral movement, because the compromised workload identity can query secrets and touch internal resources.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Ingress controllers are identity-bearing control points, not just network plumbing. Once an ingress component can modify routing, admit workloads, or read cluster objects, it functions as a non-human identity with meaningful authority. That authority must be governed like any other privileged identity because exploitability is only half the problem. The real risk is the access already attached to the workload, so practitioners should model controller trust as part of NHI governance.

Service accounts become dangerous when they inherit broad cluster visibility by default. The article shows how a single admission controller identity can expose secrets and internal network reach after compromise. That is not an edge case in Kubernetes, it is a pattern created by over-privileged runtime identities. Teams should narrow those permissions before an exploit turns a local bug into a cluster-wide event.

Runtime detections are now part of identity control, not just incident response. The monitoring examples in the article show that exposure, exploitation attempts, and secret enumeration can be observed if the right telemetry is available. NHI governance now has to include runtime evidence because static policy alone cannot prove the environment is safe. Practitioners should treat detection coverage as an access-control control plane, not an afterthought.

Patch cycles must be tied to inventory and blast-radius reduction. A vulnerable controller can remain a live identity risk even after a fix is published if teams do not know where it runs or what it can reach. The practical standard is to pair remediation with inventory, privilege review, and webhook exposure checks. For practitioners, the decision is whether the environment can fail safely before the next disclosure lands.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
• For the broader control picture, review The 52 NHI breaches Report for breach patterns that show how identity exposure becomes operational compromise.

What this signals

Identity blast radius is now the core Kubernetes governance problem. When runtime components can read secrets, admit workloads, or influence routing, a single vulnerability becomes an identity event rather than a simple patching issue. Teams should therefore map controller privileges the same way they map human privileged access, and they should align that review with NIST Cybersecurity Framework 2.0 governance and access-control expectations.

Ephemeral vulnerability windows still become long-lived exposure when identity cleanup lags. Our research shows the average estimated time to remediate a leaked secret is 27 days, which is far longer than most disclosure-to-exploit windows. That gap matters here because Kubernetes controllers often hold reusable credentials or service-account permissions that persist long after a patch is available. Practitioners should pair incident response with lifecycle controls from the NHI Lifecycle Management Guide.

Controller compromise is also an AI-agent governance warning. The same pattern that lets a workload identity inherit too much trust will appear in agentic systems that are granted tool access without narrow scope or runtime oversight. If the environment is already struggling to govern service accounts, it will struggle more with autonomous agents that can call APIs and chain actions. For threat modelling, the MITRE ATLAS adversarial AI threat matrix provides a useful vocabulary for misuse paths.

For practitioners

• Audit controller service-account privileges Review every ingress and admission controller service account for cluster-wide secret read access, broad namespace visibility, and unnecessary network reach. Remove privileges that are not required for routing or admission functions.
• Inventory all ingress-nginx versions Identify every deployed ingress-nginx instance across Kubernetes, Linux hosts, and public cloud environments, then map each instance to a specific version and patch state.
• Check validating webhook exposure Verify whether the ValidatingWebhookConfiguration is present and whether the admission service is reachable from public or pod-adjacent paths. Reduce exposure before patching is complete.
• Add detections for secret enumeration Monitor for kubectl get secrets activity, suspicious shared-object loading from temporary nginx directories, and post-exploitation commands that indicate cluster reconnaissance.
• Shorten controller blast radius Separate ingress, admission, and secret-access responsibilities where possible so one compromised component cannot automatically reach every cluster secret.

Key takeaways

• IngressNightmare shows that Kubernetes controllers can become high-value non-human identities when they carry broad privileges and secret access.
• The practical risk is not just exploitation of a bug, but the size of the trust boundary attached to the compromised workload identity.
• Teams need version inventory, privilege reduction, and runtime detection together if they want to keep controller compromise from becoming cluster compromise.

Key terms

• Ingress Controller: A Kubernetes component that receives external traffic and routes it to internal services. Because it sits at the edge of the cluster, it often has elevated visibility into configuration and workload paths, which makes its access boundaries a governance concern, not just a networking concern.
• Admission Controller: A Kubernetes control that evaluates or mutates objects before they are accepted into the cluster. If compromised or over-privileged, it can become a powerful non-human identity because it influences what workloads run and what cluster data the process can reach.
• Service Account: A workload identity used by software running inside a Kubernetes environment. It authenticates the process to the cluster and can carry permissions for secrets, objects, or network actions, so its scope determines how far an attacker can move after compromise.
• Identity Blast Radius: The amount of damage that becomes possible when a non-human identity is compromised. In practice, it is defined by the permissions, secrets, and network paths attached to the identity, not by the vulnerability that triggered the compromise.

Deepen your knowledge

Kubernetes controller identity governance is covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are mapping ingress, admission, and workload privilege in a similar environment, it is worth exploring.

This post draws on content published by CrowdStrike Engineering: IngressNightmare vulnerabilities in Kubernetes ingress-nginx. Read the original.