RCE in NGINX on Kubernetes: What You Should Know

Table of Contents

• Module 1: The Ingress Nightmare Vulnerability Chain
  • Kubernetes and the Role of the NGINX Ingress Controller
  • High-Level Overview of the Four CVEs
  • CVE-2025-1097: Configuration Injection via the auth-tls-match-cn Annotation
  • CVE-2025-1098: Configuration Injection via the Mirror Annotation
  • CVE-2025-24514: Configuration Injection via the auth-url Annotation
  • CVE-2025-1974: Unauthenticated Remote Code Execution via the Admission Controller
  • CVSS Scoring Breakdown
  • Affected Product and Version Ranges
  • Remediation, Patching, and Workarounds
  • Proof of Concept and Indicators of Compromise
• Summary

Module 1: The Ingress Nightmare Vulnerability Chain

Kubernetes and the Role of the NGINX Ingress Controller

Kubernetes (K8s) is a platform that manages and scales containers — self-contained software packages that run consistently regardless of where they are deployed. It allows complex applications to run across large numbers of servers without requiring manual, hands-on management of every component.

The NGINX Ingress Controller plays a critical role inside a Kubernetes cluster. When external users or services need to reach applications running inside the cluster — for example, visiting a website or calling an API — the ingress controller is the component that receives and handles those requests. Its responsibilities include:

• Routing incoming traffic to the correct internal service.
• Load balancing across backend pods.
• TLS termination.
• Applying security rules to incoming traffic.

Because the ingress controller sits at the very edge of the cluster’s infrastructure and is frequently exposed directly to the internet, any vulnerability in it — especially one enabling remote code execution — is extremely serious. A compromised ingress controller effectively hands an attacker the keys to route and manipulate traffic destined for everything running inside the cluster.

flowchart LR
    Internet["External Users / Services\n(Internet)"] -->|HTTP/HTTPS requests| Ingress["NGINX Ingress Controller\n(edge of cluster)"]
    Ingress -->|Routing, Load Balancing,\nTLS Termination, Security Rules| SvcA["Internal Service A"]
    Ingress --> SvcB["Internal Service B"]
    Ingress --> SvcC["Internal Service C"]

    subgraph Cluster["Kubernetes Cluster"]
        Ingress
        SvcA
        SvcB
        SvcC
    end

    style Ingress fill:#f96,stroke:#900,stroke-width:2px

High-Level Overview of the Four CVEs

Four related CVEs were disclosed together and collectively became known as “Ingress Nightmare.” At their core, these vulnerabilities are misconfigurations that allow attackers to inject malicious configuration into NGINX, which can ultimately lead to remote code execution.

What makes this vulnerability chain especially concerning is the ingress controller’s position: because it sits right at the edge of the Kubernetes cluster and handles all incoming traffic, a successful exploit does not just knock on the door of the cluster — it can walk straight in. In some cases these bugs allow an attacker to execute arbitrary code or extract secrets from across the entire cluster. In certain configurations, exploitation requires no pre-existing access at all — the attack can be carried out entirely remotely.

mindmap
  root((Ingress Nightmare))
    CVE-2025-1097
      auth-tls-match-cn annotation
      Config injection
    CVE-2025-1098
      ingress.kubernetes.io/mirror annotation
      Config injection
    CVE-2025-24514
      auth-url annotation
      Config injection
    CVE-2025-1974
      Admission controller
      SSL Engine directive
      Unauthenticated RCE

CVE-2025-1097: Configuration Injection via the auth-tls-match-cn Annotation

This vulnerability is a configuration injection issue affecting the auth-tls-match-cn ingress annotation. This annotation is intended to match a client’s TLS certificate against a set of allowed Common Names (CNs). However, the value supplied to this annotation is not properly sanitized before being incorporated into the generated NGINX configuration.

As a result, an attacker who already has the ability to create or edit Ingress objects in the cluster can inject arbitrary NGINX directives through this annotation. Controlling the resulting NGINX configuration allows an attacker to:

• Bypass security rules enforced by the ingress controller.
• Redirect traffic to attacker-controlled destinations.
• Expose internal services that should not be reachable externally.

By itself, this issue is a configuration injection vulnerability rather than a full remote code execution, but it represents a solid stepping stone toward a more severe compromise.

# Conceptual example of a malicious annotation value abusing improper sanitization
# of the auth-tls-match-cn annotation to inject arbitrary NGINX configuration.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: malicious-ingress
  annotations:
    nginx.ingress.kubernetes.io/auth-tls-match-cn: "CN=attacker\";\n# injected directive here\n#"
spec:
  rules:
    - host: example.internal
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: internal-service
                port:
                  number: 80

CVE-2025-1098: Configuration Injection via the Mirror Annotation

This vulnerability is structurally very similar to CVE-2025-1097, but affects a different annotation: the nginx.ingress.kubernetes.io/mirror annotation. Again, the ingress controller fails to properly sanitize the input supplied to this annotation, allowing arbitrary NGINX configuration to be injected.

As with CVE-2025-1097, this gives an attacker a way to interfere with:

• Traffic routing decisions.
• Logging behavior.
• Access control rules.

This is achieved simply by crafting a malicious Ingress resource that sets a specially-formed value for the mirror annotation.

CVE-2025-24514: Configuration Injection via the auth-url Annotation

This third configuration injection vulnerability affects the auth-url annotation, which is supposed to define an external authentication service that the ingress controller calls out to before allowing a request through. Once again, insufficient input sanitization allows an attacker to inject arbitrary NGINX directives into this annotation’s value.

This vulnerability is considered particularly dangerous because it can be abused to:

• Redirect users to attacker-controlled destinations.
• Expose sensitive data.
• Be chained together with other vulnerabilities in this set to escalate toward full remote code execution.

CVE-2025-1974: Unauthenticated Remote Code Execution via the Admission Controller

This is the most critical vulnerability in the Ingress Nightmare set, and the one that elevates the overall risk from configuration tampering to full system compromise.

This vulnerability affects the admission controller component, which is responsible for inspecting and validating incoming Kubernetes resource definitions before they are persisted to the cluster. An attacker can craft a specially formed admission review request that includes a directive called ssl_engine. The NGINX ingress controller passes this directive through as though it were a valid configuration value. Because of how the ssl_engine directive is processed, an attacker who understands how to leverage it can use it to execute arbitrary code inside the ingress controller process itself.

Once an attacker achieves code execution inside the admission controller, they gain a foothold inside the cluster with elevated privileges — a significant escalation from the configuration-tampering behavior seen in the other three CVEs.

sequenceDiagram
    participant Attacker
    participant K8sAPI as Kubernetes API Server
    participant AdmCtrl as Admission Controller\n(NGINX Ingress)
    participant Cluster as Kubernetes Cluster

    Attacker->>K8sAPI: Submit crafted AdmissionReview request\ncontaining "ssl_engine" directive
    K8sAPI->>AdmCtrl: Forward AdmissionReview for validation
    AdmCtrl->>AdmCtrl: Parses request, treats ssl_engine\ndirective as valid NGINX configuration
    AdmCtrl->>AdmCtrl: ssl_engine directive triggers\narbitrary code execution
    AdmCtrl-->>Attacker: Code executes inside\nadmission controller process
    Attacker->>Cluster: Foothold with elevated privileges\ninside cluster

CVSS Scoring Breakdown

Considering risk in broader terms than technical mechanics alone, the CVSS scores for the four Ingress Nightmare vulnerabilities show a clear standout, along with important nuance among the rest:

For the three vulnerabilities scored at 8.8, the single factor keeping them just below the “Critical” threshold is that they require low privileges — meaning the attacker must already have some level of access inside the K8s cluster, such as the ability to create or edit ingress resources. Every other component of the vector for these three reflects high risk:

• Remotely exploitable.
• Low attack complexity.
• No user interaction required.
• High impact across confidentiality, integrity, and availability.

CVE-2025-1974 scores higher at 9.8 because it requires no privileges at all — it can potentially be exploited without any pre-existing access to the cluster, making it a true unauthenticated remote code execution vulnerability. Like the other three, it also has low attack complexity, requires no user interaction, and has high impact.

xychart-beta
    title "Ingress Nightmare CVSS Scores"
    x-axis ["CVE-2025-1097", "CVE-2025-1098", "CVE-2025-24514", "CVE-2025-1974"]
    y-axis "CVSS Score" 0 --> 10
    bar [8.8, 8.8, 8.8, 9.8]

The key takeaway is that even though only one of these four vulnerabilities crosses the “Critical” threshold, all four represent high-risk vulnerabilities, particularly in clusters where the privilege barrier for creating or editing ingress resources is low or misconfigured. Organizations should treat all four with the same level of urgency: the difference between an 8.8 and a 9.8 score is not about how severe the ultimate outcome is, but about how easy it is for an attacker to reach that outcome.

Affected Product and Version Ranges

The vulnerabilities specifically affect the ingress-nginx controller for Kubernetes (often referred to simply as “ingress-nginx”) — an open source component that manages external access to services within Kubernetes clusters, using NGINX as a reverse proxy and load balancer.

It is important to note the scope of impact precisely:

• The vulnerabilities are confined to the ingress-nginx controller specifically.
• They do not directly impact Kubernetes itself.
• They do not directly impact the standard, general-purpose NGINX web server/software.

The affected version ranges are:

This split — rather than a single blanket statement of “all versions prior to 1.12.0” — exists because different vulnerabilities affect different sets of features, and some of those features were only introduced in specific releases:

• The admission controller, where the RCE vulnerability lives, was not part of the project until version 1.11.0. Any version before that could not be affected by the admission-controller RCE specifically, though it could still be vulnerable to the earlier configuration-injection issues.
• Versions 1.11.0 through 1.11.4 include the admission controller but do not yet contain the fixes, so they are vulnerable to the full set of issues, including remote code execution.
• Version 1.12.0 is a newer release that shipped before the security fixes were ready. Even though it was the latest version at the time of its release, it remains vulnerable — and because it is built slightly differently under the hood compared to the 1.11.x line, patches for it need to be applied differently.

flowchart TD
    A["ingress-nginx version"] --> B{"Version < 1.11.0?"}
    B -->|Yes| C["No admission controller present\nVulnerable only to config-injection\nCVEs 1097 / 1098 / 24514"]
    B -->|No| D{"Version in 1.11.0 - 1.11.4?"}
    D -->|Yes| E["Admission controller present,\nfixes not yet applied\nVulnerable to ALL 4 CVEs\n(incl. RCE 1974)"]
    D -->|No| F{"Version == 1.12.0?"}
    F -->|Yes| G["Admission controller present,\nshipped before fixes\nVulnerable to ALL 4 CVEs\n(incl. RCE 1974)"]
    F -->|No| H["Version >= 1.12.1 or >= 1.11.5\nPatched"]

Remediation, Patching, and Workarounds

The most effective fix for these vulnerabilities is to patch to a corrected release:

• Upgrade to version 1.12.1 if running on the 1.12.x line.
• Upgrade to version 1.11.5 if remaining on the 1.11.x line.

Since immediate patching is not always possible, the following mitigation steps can reduce risk in the interim:

1. Restrict access to the admission controller. If it is in use, ensure it is not exposed outside the cluster, and ideally restrict access with network policies or firewall rules so that only trusted components can reach it.
2. Audit and sanitize ingress annotations. Set up validation webhooks or admission policies — for example using Gatekeeper or Kyverno — to block or flag Ingress resources that use suspicious annotations or contain potentially dangerous content.
3. Limit who can create or modify Ingress resources. Because these vulnerabilities rely on an attacker being able to submit crafted ingress definitions, restricting that ability directly blocks exploitation. Use Kubernetes RBAC to ensure only trusted service accounts or users can create or update ingress configurations.
4. Use read-only role separation. Prevent service accounts from having unnecessary write permissions in namespaces where the ingress controller operates.

flowchart TD
    Start(["Can you patch immediately?"]) -->|Yes| Patch["Upgrade to 1.12.1 (1.12.x line)\nor 1.11.5 (1.11.x line)"]
    Start -->|No| Mitigate["Apply interim mitigations"]
    Mitigate --> M1["Restrict/network-isolate\nadmission controller"]
    Mitigate --> M2["Validate/sanitize ingress\nannotations via Gatekeeper/Kyverno"]
    Mitigate --> M3["Restrict RBAC on who can\ncreate/edit Ingress resources"]
    Mitigate --> M4["Enforce read-only role\nseparation for service accounts"]
    M1 --> Patch
    M2 --> Patch
    M3 --> Patch
    M4 --> Patch

Proof of Concept and Indicators of Compromise

The original security research that led to the discovery of these vulnerabilities was carried out by Wiz, who published a detailed report of their work, including the full narrative of how the vulnerabilities were identified along with proof-of-concept code used to validate the findings.

As of the time this material was recorded, there were no widely recognized, specific indicators of compromise unique to these vulnerabilities. However, several proactive monitoring and auditing steps are recommended:

• Watch for unusual network activity around the ingress controller pod. Unexpected outbound connections to unfamiliar IPs or destinations that are not part of normal operations are a major red flag.
• Watch for abnormal resource usage. Sudden spikes in CPU or memory usage on the ingress controller could indicate something is going wrong.
• Review ingress resource definitions. Since the injection vulnerabilities depend on malicious annotation values, review all Ingress definitions for suspicious use of annotations such as auth-url or auth-tls-match-cn. Unexpected configuration values or strange content in those fields can indicate tampering.
• Review ingress controller logs. Look for unusual patterns such as repeated failed access attempts, strange error messages, or unusual request paths. Even short of full RCE evidence, earlier reconnaissance or misconfigured exploitation attempts will often surface in logs first.
• Stay engaged with the community. Following GitHub issues, mailing lists, and vendor advisories for both Kubernetes and NGINX helps surface newly discovered indicators of compromise or reports of active exploitation quickly, rather than operating with stale information.

flowchart TD
    Monitor["Ongoing Monitoring"] --> Net["Unusual outbound traffic\nfrom ingress controller pod"]
    Monitor --> Res["Unexpected CPU/memory spikes"]
    Monitor --> Ing["Suspicious values in\nauth-url / auth-tls-match-cn\nannotations"]
    Monitor --> Logs["Repeated failed access attempts,\nunusual error messages,\nunusual request paths"]
    Monitor --> Community["Community intel: GitHub issues,\nmailing lists, vendor advisories"]
    Net --> Alert["Investigate as potential\nexploitation attempt"]
    Res --> Alert
    Ing --> Alert
    Logs --> Alert
    Community --> Alert

Summary

The “Ingress Nightmare” vulnerability chain consists of four related CVEs affecting the ingress-nginx controller for Kubernetes:

• CVE-2025-1097 — configuration injection via the auth-tls-match-cn annotation (CVSS 8.8, low privileges required).
• CVE-2025-1098 — configuration injection via the mirror annotation (CVSS 8.8, low privileges required).
• CVE-2025-24514 — configuration injection via the auth-url annotation (CVSS 8.8, low privileges required).
• CVE-2025-1974 — unauthenticated remote code execution via the admission controller’s ssl_engine directive handling (CVSS 9.8, no privileges required).

All four stem from insufficient sanitization of user-controllable input — either ingress annotation values or admission review requests — that the ingress controller passes through into its generated NGINX configuration. The most severe of the four allows a fully unauthenticated attacker to achieve arbitrary code execution inside the admission controller, gaining an elevated-privilege foothold inside the Kubernetes cluster. Because the ingress controller sits at the network edge of the cluster and is frequently internet-facing, the practical risk of this vulnerability chain is high regardless of which individual CVSS score applies.

Affected versions include all releases prior to 1.11.0 (configuration-injection issues only), 1.11.0 through 1.11.4, and 1.12.0 (full vulnerability set including RCE, since the admission controller was present but unpatched in those releases).

Mitigation Checklist

• Identify all ingress-nginx controller deployments and their exact version numbers across all clusters.
• Patch to version 1.12.1 (if on the 1.12.x line) or 1.11.5 (if on the 1.11.x line) as the primary remediation.
• If immediate patching is not possible, restrict network access to the admission controller so it is unreachable from outside the cluster.
• Deploy validation webhooks or admission policies (e.g., Gatekeeper, Kyverno) to detect and block suspicious values in ingress annotations such as auth-url, auth-tls-match-cn, and mirror annotations.
• Apply Kubernetes RBAC restrictions so only trusted service accounts or users can create or modify Ingress resources.
• Enforce read-only role separation for service accounts operating in namespaces where the ingress controller runs.
• Monitor ingress controller pods for unusual outbound network activity and abnormal CPU/memory usage.
• Audit existing Ingress resource definitions and controller logs for signs of tampering, failed access attempts, or unusual request patterns.
• Review the Wiz research report and published proof-of-concept material to understand exploitation mechanics in more depth.
• Subscribe to Kubernetes and NGINX community channels (GitHub issues, mailing lists, vendor advisories) to stay current on newly disclosed indicators of compromise or active exploitation activity.

Search Terms

rce · nginx · kubernetes · know · vulnerability · briefings · networking · systems · security · via · annotation · configuration · injection · controller · ingress