Case study: ingress-nginx CVE-2025-1974 and the exposed admission webhook (2025)

ingress-nginx was the Kubernetes project's own ingress controller: it turned Ingress objects into nginx configuration and routed outside traffic to applications. The project's security blog said it was 'deployed in over 40% of Kubernetes clusters'. On 24 March 2025 the maintainers released v1.12.1 and v1.11.5 with fixes for five vulnerabilities, and the Kubernetes Security Response Committee called the situation 'very serious'.

Four of the bugs were about how the controller handled pieces of nginx configuration: 'a specially-crafted Ingress object can cause nginx to misbehave in various ways, including revealing the values of Secrets that are accessible to ingress-nginx.' Normally, exploiting them would need permission to create an Ingress, 'a fairly privileged action'. The fifth, CVE-2025-1974, rated 9.8, removed that requirement: it 'allows anything on the Pod network to exploit configuration injection vulnerabilities via the Validating Admission Controller feature of ingress-nginx.' In the project's words, 'anything on the Pod network has a good chance of taking over your Kubernetes cluster, with no credentials or administrative access required.'

The vulnerabilities were reported by researchers at Wiz, who named them IngressNightmare. The Kubernetes issue for CVE-2025-1974 stated: 'There are no known indicators of compromise that prove this vulnerability has been exploited', and the CVE is not in CISA's KEV catalog.

A validating admission webhook is an HTTPS service that the Kubernetes API server calls to approve or reject objects before it stores them. ingress-nginx ran one inside the controller pod, on port 8443 in the Helm chart's defaults, to warn users about broken Ingress configurations. The issue for CVE-2025-1974 states the flaw plainly: 'an unauthenticated attacker with access to the pod network can achieve arbitrary code execution in the context of the ingress-nginx controller.' The webhook did not check that its caller was the API server.

Wiz, which found the bugs, describes the rest: when the admission controller processes a request it renders a temporary nginx configuration from the Ingress object and tests it with nginx -t, so injected directives were evaluated during validation. That detail is from Wiz's write-up, not the Kubernetes advisories, which describe only 'configuration injection'. The three injection CVEs named the fields involved: the auth-url, auth-tls-match-cn, and mirror-target and mirror-host annotations. For CVE-2025-24514, the issue notes that the enable-annotation-validation argument, on by default from v1.12.0, prevents it.

This is the injection pattern the injection guide (/domains/appsec/secure-coding/injection-parser-boundaries/) describes, in infrastructure code: user-controlled strings copied into a configuration language that has powerful directives. Treat annotations and snippets as untrusted input to a parser, validate them against a strict grammar, and never pass them through to a configuration file unescaped.

Code execution in a controller pod is bad; what made this cluster-wide was the controller's permissions. Both the blog and the issues repeat the point: 'in the default installation, the controller can access all Secrets cluster-wide.' An ingress controller needs TLS certificates, so its service account was given read access to Secrets in every namespace, and that includes service account tokens, database passwords and cloud credentials.

The Pod network was the other half. The blog warns that 'In many common scenarios, the Pod network is accessible to all workloads in your cloud VPC, or even anyone connected to your corporate network!' Wiz reported that about 43% of cloud environments it analyzed were vulnerable and that it found over 6,500 clusters exposing vulnerable admission controllers to the public internet; those are Wiz's figures, not the project's.

In the OWASP Kubernetes Top 10 (2025 edition) this sits across K06 Overly Exposed Kubernetes Components, K02 Overly Permissive Authorization Configurations and K05 Missing Network Segmentation Controls. The workload security guide (/domains/runtime/containers/kubernetes-workload-security/) covers service account scoping, and the Secrets guide (/domains/identity-crypto/secrets/secrets-in-kubernetes-and-runtime/) what a stolen Secret exposes.

The fix was to upgrade to v1.12.1, v1.11.5 or later. For teams that could not upgrade at once, the blog's interim mitigation was to turn off the Validating Admission Controller: with Helm, reinstall with controller.admissionWebhooks.enabled=false; for manual installs, delete the ValidatingWebhookConfiguration called ingress-nginx-admission and remove --validating-webhook from the controller's arguments. And then: 'remember to turn it back on after you upgrade', because the webhook catches broken Ingress objects before they take effect.

The story did not end with the patch. On 11 November 2025 Kubernetes SIG Network and the Security Response Committee announced the retirement of ingress-nginx: 'Best-effort maintenance will continue until March 2026. Afterward, there will be no further releases, no bugfixes, and no updates to resolve any security vulnerabilities that may be discovered.' Existing deployments keep working and artifacts stay available, and the GitHub repository is now archived. They recommend Gateway API, or another maintained ingress controller, and urge users to begin migrating immediately. A controller that receives no security fixes is a standing exposure; record it in your dependency inventory like any end-of-life component (/domains/appsec/vulnerability-response/dependency-vulnerability-response/).

The blog's check finds pods by the standard label. The script below reads the full pod list instead, so it also catches controllers installed under other labels, and reports each controller image with a verdict. It ran with Python 3.14 on a sample pod list: v1.12.0 and v1.9.6 were flagged as vulnerable, v1.11.5 as fixed but retired. Image tags can lie about what is inside; when in doubt, check the digest against the project's release notes.

"""List ingress-nginx controllers and flag versions without the March 2025 fixes.

Usage: kubectl get pods -A -o json | python3 find_ingress_nginx.py
Fixed: v1.11.5 and v1.12.1 (CVE-2025-1974 and four related CVEs). The project
was retired in March 2026, so every version is now unsupported: plan a migration.
"""
import json
import re
import sys

FIXED = {(1, 11): (1, 11, 5), (1, 12): (1, 12, 1)}


def verdict(version):
    if version is None:
        return "unknown version: check the image"
    fixed = FIXED.get(version[:2])
    if version < (1, 11, 0) or (fixed and version < fixed):
        return "VULNERABLE to CVE-2025-1974: upgrade or disable the admission webhook"
    return "has the March 2025 fixes; project retired, plan a migration"


for pod in json.load(sys.stdin)["items"]:
    for container in pod["spec"]["containers"]:
        image = container["image"]
        if "ingress-nginx/controller" not in image:
            continue
        match = re.search(r":v(\d+)\.(\d+)\.(\d+)", image)
        version = tuple(map(int, match.groups())) if match else None
        meta = pod["metadata"]
        print(f"{meta['namespace']}/{meta['name']}: {image.split('@')[0]}: {verdict(version)}")

A webhook should accept connections only from the API server. The NetworkPolicy below selects the controller pods by the Helm chart's labels, keeps ports 80 and 443 open for the traffic the controller serves, and allows the webhook port, 8443 by default, only from an IP range. Which range depends on the cluster: on self-managed clusters it is the control-plane nodes; on managed services the control plane is usually outside the cluster network, so check your provider's documentation for the source addresses of webhook calls. The policy parses as valid YAML but was not applied to a live cluster for this page; test it with a positive and a negative probe as the network policy guide (/domains/runtime/containers/container-network-admission/) describes. It needs a network plugin that enforces NetworkPolicy.

# Allow client traffic to the controller, and the admission webhook port only
# from the API server. Replace the CIDR with the address range your control
# plane uses to call webhooks; on managed clusters, check your provider's docs.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: ingress-nginx
      app.kubernetes.io/component: controller
  policyTypes: [Ingress]
  ingress:
    - ports: # the traffic the controller exists to serve
        - {port: 80, protocol: TCP}
        - {port: 443, protocol: TCP}
    - from:
        - ipBlock: {cidr: 10.0.0.0/28} # placeholder: your control plane's source range
      ports:
        - {port: 8443, protocol: TCP} # validating admission webhook (chart default)

• Every admission webhook is a network service inside your cluster. Restrict who can call it.
• Configuration languages are code. User input that becomes nginx, Envoy or any other configuration needs the same care as SQL.
• Scope controller permissions: read access to all Secrets turns any controller bug into a cluster compromise.
• A flat Pod network makes every pod an attacker's starting point. Default-deny between namespaces.
• Track the lifecycle of add-ons, not just their versions: ingress-nginx is now retired and will not be fixed again.

The Kubernetes advisories do not describe the exploitation technique beyond 'configuration injection' through the admission controller; the nginx -t mechanism comes from Wiz's write-up. The figures of about 43% of cloud environments and more than 6,500 exposed clusters are Wiz's estimates from its own data, and the over-40% deployment share is the Kubernetes blog's statement. No exploitation was known when the issues were published, and CVE-2025-1974 is not in CISA's KEV catalog as of its 8 October 2026 version; that is not proof it was never exploited. What happens to vulnerabilities found in ingress-nginx after March 2026 is set only by the retirement announcement: they will not be fixed by the project.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. Kubernetes blog: Ingress-nginx CVE-2025-1974, what you need to know. 24 March 2025, links revised May 2025.
2. kubernetes/kubernetes issue 131009: CVE-2025-1974, ingress-nginx admission controller RCE escalation. 23 March 2025.
3. kubernetes/kubernetes issue 131006: CVE-2025-24514, configuration injection via the auth-url annotation. 23 March 2025.
4. ingress-nginx release controller-v1.12.1. 25 March 2025 (UTC).
5. Kubernetes blog: Ingress NGINX retirement, what you need to know. 11 November 2025.
6. Kubernetes documentation: Dynamic admission control
7. OWASP Kubernetes Top 10 (2025). 2025 edition.
8. Wiz (third-party research, discoverer): IngressNightmare, CVE-2025-1974 in Kubernetes. 24 March 2025.

Reference information

Tags

InjectionSecrets managementKubernetes and containersVulnerability management

SDLC phase

DevelopmentMaintenance

Role

DevelopersPlatform engineers and SREs

Download this guide as Markdown

Continue exploring