CVE-2025-1974 IngressNightmare: critical ingress-nginx RCE

CVE-2025-1974, commonly called IngressNightmare, is a critical ingress-nginx vulnerability rated 9.8 under CVSS 3.1. This is not a routine reverse-proxy misconfiguration. An unauthenticated actor with network access to the admission controller can abuse configuration injection, execute code in the ingress controller and reach secrets available to its service account. In a common deployment, the result may be a full Kubernetes cluster compromise.

Immediate recommendation: inventory every cluster, upgrade ingress-nginx to at least 1.11.5 or 1.12.1, restrict access to the admission webhook and treat a reachable vulnerable controller as a potential breach path. A WAF in front of the application does not remove this vulnerability.

Confirmed CVE-2025-1974 facts

Attribute	Confirmed information
Product	Kubernetes ingress-nginx controller
Severity	CVSS 3.1: 9.8 — critical
Vulnerable versions	all releases before 1.11.0, versions 1.11.0–1.11.4 and 1.12.0
Fixed versions	1.11.5, 1.12.1 and later
Attack condition	network access to the admission controller; no credentials required
Impact	controller RCE, access to secrets and potential cluster takeover
Disclosure	24 March 2025 by the Kubernetes Security Response Committee
Public PoC	yes — demonstration code is publicly available

The scope is documented in the official Kubernetes announcement and the Kubernetes community advisory. The product name matters: this CVE affects the ingress-nginx project, not every NGINX-branded product or every Kubernetes ingress controller.

How IngressNightmare works

Ingress-nginx converts Kubernetes Ingress resources into NGINX server configuration. Before the API stores an object, it may send that object to the Validating Admission Controller so the controller can verify it. That internal validation endpoint expands the attack surface.

CVE-2025-1974 lets an actor who can reach the admission webhook send input that leads to NGINX configuration injection. It is particularly dangerous when chained with the configuration-processing flaws released in the same patch set. Crafted configuration can cause attacker-controlled data to be loaded and code to execute in the ingress controller process.

Technical root cause and trust boundaries

The admission webhook receives an AdmissionReview object from the API server and evaluates a proposed Ingress before storage. During that work ingress-nginx generates configuration and validates it. The critical trust boundary therefore spans the webhook input, NGINX configuration generator and controller process with Kubernetes API access. The official Kubernetes announcement describes CVE-2025-1974 as a way to reach configuration-injection weaknesses through the Validating Admission Controller; the complete RCE impact comes from combining that reachability with the configuration-handling flaws fixed in the same release.

There is no need to assign an unverified payload property to the CVE. The documented defensive model is sufficient: an unauthenticated party with webhook connectivity can execute code in the controller context. The NVD entry for CVE-2025-1974 confirms the Pod-network prerequisite, RCE and disclosure of secrets available to the controller.

Attack-surface model

Question	Evidence to collect	Why it matters
Is admission enabled?	controller arguments, Service and `ValidatingWebhookConfiguration`	this specific path is absent when the feature is inactive
Who can reach the Service?	NetworkPolicy, CNI, VPC, VPN, peering and hostNetwork	`ClusterIP` does not imply isolation
Which version is running?	tag, digest and version in every live Pod	a changed manifest does not prove rollout completion
What can the controller identity do?	Role, ClusterRole, bindings and mounted tokens	this defines post-RCE reach
Which secrets are reachable?	namespaces, TLS Secrets, external mounts and cloud identity	this determines the required rotation scope

Apply zero-trust network and service principles: a workload should not receive access merely because it runs inside the cluster.

It would be inaccurate to say that every vulnerable cluster is directly exploitable by anyone on the Internet. The official advisory identifies network access to the Pod network or admission controller as the prerequisite. In many environments, however, that path is available to every cluster workload, resources in the same cloud VPC, corporate network hosts or VPN-connected systems. A compromise of a low-value application may therefore become the first step toward the traffic-management plane.

Why the flaw can lead to cluster takeover

An ingress controller reads TLS secrets and service configuration to terminate HTTPS and route traffic. Kubernetes noted that default ingress-nginx deployments often had access to secrets across the cluster. Code execution in the controller Pod can therefore extend far beyond that container’s filesystem.

A realistic impact chain is:

an attacker obtains connectivity to the admission webhook;
the IngressNightmare chain executes code in the controller;
the attacker reads a service-account token, TLS secrets or configuration available to that process;
excessive RBAC privileges enable further enumeration and workload compromise;
persistence is established through modified resources, images or secrets.

Actual impact depends on RBAC, segmentation and secret management. Prioritisation must therefore consider internal network paths and service-account permissions, not only whether the public application is reachable.

Public PoC and safe validation

A public IngressNightmare CVE-2025-1974 PoC demonstrates the technical issue. Treat the repository as potentially dangerous code. Never run it against production, third-party clusters or systems without explicit written authorisation.

Safer validation does not require proving RCE. A defensive team can:

inventory clusters for workloads labelled app.kubernetes.io/name=ingress-nginx;
read the running controller image version from its Deployment or DaemonSet;
identify ingress-nginx-admission and every network route to the webhook;
review the controller service account, especially cross-namespace secret access;
validate the patch against a cloned or isolated lab environment;
verify the versions of running Pods after deployment rather than relying on a changed Helm values file.

A single negative PoC result is not a clean bill of health. It may reflect one topology, intermediate control or tooling issue. It does not make a vulnerable component safe.

Safe exposure validation without RCE

Confirm presence, then version, then reachability, and finally blast radius. A network check can originate from an approved diagnostic Pod and establish only whether the admission Service accepts a connection, without sending an object that exercises the vulnerability. Record results separately for ordinary workloads, administration namespaces, nodes, VPC networks, VPNs and peering connections.

Establish version from several artefacts: workload specification, image digest, live Pods and registry or SBOM data. One replica on a vulnerable image means the service is not fully remediated. Then use can-i or equivalent RBAC analysis for the controller service account without reading secret values. This provides sufficient prioritisation evidence and aligns with the verification mindset in OWASP ASVS 5, even though the vulnerable component is application infrastructure.

Triage decision tree

No ingress-nginx present — close the item after documenting the actual controller.
Ingress-nginx with admission disabled — this CVE has no active vector; still assess the companion CVEs and plan the update.
Admission enabled and fixed release deployed — verify every replica, digest and network boundary, then run negative retesting.
Vulnerable release but webhook unreachable from untrusted zones — patch urgently, document the compensating control and test indirect paths.
Vulnerable and reachable webhook — isolate, upgrade as an emergency, preserve logs and start threat hunting.
Evidence of code execution or credential use — handle it as an incident rather than a patch-management ticket.

How to remediate CVE-2025-1974

Upgrade the controller

The durable fix is ingress-nginx 1.11.5, 1.12.1 or a newer supported release. Check both the Helm chart and the tag or digest of the image that is actually running. Large organisations should query their central cluster inventory or CSPM platform rather than sample a few environments manually.

Restrict the admission controller

Where an immediate upgrade is impossible, Kubernetes recommends temporarily disabling the Validating Admission Controller. Helm deployments control it through controller.admissionWebhooks.enabled=false. This is an emergency mitigation, not an equivalent fix. The webhook provides useful pre-deployment validation and can be restored after the upgrade.

Even after patching, admission endpoints should be reachable only from required control-plane components. NetworkPolicy, VPC firewall policy and segmentation reduce the chance that a future webhook flaw becomes a cluster-wide incident.

Reduce blast radius

The controller service account should have the narrowest practical scope. A controller serving selected namespaces should not automatically read every cluster secret. Separate controllers by trust zone and avoid mounting unnecessary identity tokens or cloud credentials.

Remediation verification and retesting

Retesting must establish more than a new version string:

every Deployment, DaemonSet and Pod uses the fixed digest;
no orphan replica, old node or parallel Helm installation remains;
an untrusted namespace cannot connect to the admission Service under the intended policy;
the control plane can still perform legitimate Ingress validation;
a harmless disallowed object is rejected safely in an isolated environment;
the controller service account cannot read secrets outside its required scope;
rollout, logs and alerts show no crash loop, webhook failure or alternate exposed route.

Positive functional validation matters alongside negative security tests. Disabling the webhook may reduce risk, but a broken admission path can halt deployments. Organisations performing recurring web application and infrastructure penetration testing should add this scenario to regression checks after ingress or CNI changes.

Detection and post-disclosure threat hunting

An upgrade closes the vulnerability but does not remove evidence of an earlier intrusion. For reachable vulnerable installations, review:

Kubernetes Audit events involving ValidatingWebhookConfiguration, Ingress, Secret, RoleBinding and ClusterRoleBinding resources;
admission-controller logs for unusual, rejected or repeated requests;
child processes, unexpected network utilities and outbound traffic from controller Pods;
service accounts, tokens, secrets and workloads created outside CI/CD;
new images, init containers, hostPath volumes and privileged Pods;
use of TLS secrets and cloud credentials after the earliest possible exposure date.

There is no universal IOC that reliably proves or excludes exploitation. Treat these as telemetry signals, not an exploit signature. High-confidence correlation combines an unusual admission call, a controller-process anomaly, unexpected egress and later use of a secret or Kubernetes resource change. Preserve timestamp, source IP or Pod identity, request UID, namespace, resource name and webhook result. Avoid retaining full objects when they may contain sensitive data.

If code execution is suspected, restarting the Pod is not enough. Preserve logs, isolate the node or namespace, rotate every reachable secret and token, examine the control plane, and rebuild from trusted state under the incident-response process.

Kubernetes administrator checklist

The wider Kubernetes lesson

IngressNightmare demonstrates that an “internal” component is not automatically trusted. Admission webhooks process complex API-supplied data, while controllers often hold broad privileges. Cluster security reviews should therefore cover public services, container image controls, RBAC and segmentation, as well as the control paths between them.

If you need to establish exposure without risky production exploitation, we can conduct an authorised cloud and Kubernetes penetration test with safe evidence collection, remediation guidance and a formal retest.