CVE-2025-1974

This vulnerability is like a back door in the “admission controller” that decides what Kubernetes changes are allowed. If someone finds and reaches the vulnerable component, they can run arbitrary code on it from the network—similar to taking control of the system that approves and routes changes for your cluster. That can quickly lead to total compromise of what your Kubernetes setup can see and do, including outages.

This matters if you run Kubernetes with ingress-nginx (k8s.io/ingress-nginx) and that admission controller component is reachable in your environment. It’s especially relevant when ingress-nginx is exposed over the network and can be reached by an attacker.

The risk is tied to whether an attacker can reach the vulnerable ingress-nginx admission controller over the network (no authentication or user interaction is required per the findings).

This should be treated as a RED incident because the bug allows remote code execution with no authentication, and public proof-of-concept code exists. Even though there is no dated public reporting of real exploitation in the provided materials, you should assume a rapid escalation path for attackers and patch immediately.

Given the critical impact described (confidentiality, integrity, and availability), the only sensible response for a business is to reduce exposure now and upgrade to a fixed version without delay.

1. Identify the running version

   • In your Kubernetes namespace(s), find the ingress-nginx controller Deployment/DaemonSet/Pod (whatever you use: Helm, manifests, or an operator).
   • Determine the ingress-nginx version from the chart/image tag you deployed.
   • Treat versions earlier than 1.11.5 (and, depending on your upgrade track, earlier than 1.12.1) as needing remediation.

2. Confirm whether the Validating Admission Controller is enabled

   • Check your ingress-nginx configuration values/manifests for the Validating Admission Controller functionality.
   • If it is enabled and you are on an affected version, prioritize the upgrade.

3. Upgrade to the fixed release

   • Upgrade ingress-nginx to:
     • 1.11.5, or
     • 1.12.1 (newer track)
   • Follow your normal deployment method (Helm release upgrade or manifest update) and ensure pods become Ready.

4. Temporary workaround if patching is delayed

   • Disable the Validating Admission Controller functionality of ingress-nginx before the attacker has a chance to exploit it.
   • Keep it disabled only until the fixed upgrade is applied, then re-evaluate your configuration.

5. Post-upgrade verification

   • Confirm the ingress-nginx admission controller component is running the new version.
   • Confirm no configuration drift re-enables the vulnerable exposure settings.

6. What to monitor

   • Look for unexpected changes targeting Kubernetes admission behavior.
   • Review logs around ingress-nginx admission controller activity for anomalies (especially around the time of any deployments/config changes).

Severity is critical (reported by the CVE’s scoring) with a mechanism consistent with CWE-653 (Improper Neutralization of Special Elements used in an SQL Command / broader class: escaping/handling leading to code execution). The findings state remote execution of arbitrary code over the network with no required credentials and no user interaction, resulting in total compromise of confidentiality, integrity, and availability.

Exploitation status: the provided materials do not list CVE-2025-1974 in the CISA KEV set and do not provide dated press claims of exploitation. However, public proof-of-concept code exists on GitHub (3 known). The EPSS prediction is extremely high and rising, but it is only a prediction; the system verdict for this issue is RED regardless.

Known fixed versions: 1.11.5 and 1.12.1. A mitigation/workaround noted in the findings is to disable the Validating Admission Controller functionality of ingress-nginx until the upgrade is completed.