CVE-2026-24512: 
Ingress NGINX Controller (community-driven) vulnerability analysis and mitigation

CVE-2026-24512 is a configuration injection vulnerability in Kubernetes ingress-nginx where the rules.http.paths.path Ingress field can be used to inject arbitrary configuration into nginx, leading to remote code execution and Kubernetes Secret disclosure. It was discovered by Maxime Escourbiac and Yassine Bengana (Michelin CERT) and disclosed on February 2–4, 2026. Affected versions are ingress-nginx < v1.13.7 and >= v1.14.0, < v1.14.3. It carries a CVSS v3.1 base score of 8.8 (High) (GitHub Advisory, Kubernetes Issue).

The root cause is improper input validation (CWE-20) of the rules.http.paths.path field in Kubernetes Ingress resources processed by the ingress-nginx controller. The controller uses this field to generate nginx configuration files without sufficiently sanitizing user-supplied input, allowing an attacker with permission to create or modify Ingress resources to inject arbitrary nginx directives. Exploitation requires only low-level privileges (e.g., the ability to create Ingress objects in a namespace) and no user interaction, making it accessible to any authenticated cluster user with such RBAC permissions. The injected configuration is interpreted by the nginx process running inside the controller pod, enabling arbitrary command execution in that context (GitHub Advisory, Kubernetes Issue).

Successful exploitation allows an attacker to execute arbitrary code within the ingress-nginx controller pod and access all Kubernetes Secrets that the controller can read — which in the default installation includes all Secrets cluster-wide. This represents a critical breach of cluster confidentiality and integrity, as Secrets typically contain credentials, API tokens, TLS certificates, and other sensitive data. The combination of code execution and broad Secret access could enable full cluster compromise and lateral movement to other workloads or cloud environments (GitHub Advisory, Kubernetes Issue).

As of the time of disclosure, no public proof-of-concept exploit code had been observed, and there is no confirmed evidence of in-the-wild exploitation (Feedly). The EPSS score is approximately 0.082–0.095%, placing it in the 24th percentile for near-term exploitation likelihood. The vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. However, the low privilege requirement and network-accessible attack vector make it an attractive target for threat actors with any foothold in a Kubernetes cluster.

1. Reconnaissance: Identify clusters running a vulnerable version of ingress-nginx (< v1.13.7 or >= v1.14.0 and < v1.14.3) using kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx.
2. Obtain low-privilege access: Acquire credentials or a service account with permission to create or modify Ingress resources in at least one namespace (e.g., via a compromised application pod or misconfigured RBAC).
3. Craft malicious Ingress resource: Create an Ingress manifest where the rules.http.paths.path field contains injected nginx configuration directives — for example, embedding a location block with a Lua script or an exec directive that triggers command execution.
4. Apply the Ingress resource: Submit the crafted Ingress to the cluster using kubectl apply -f malicious-ingress.yaml. The ingress-nginx controller processes the path field and writes the injected directives into the nginx configuration.
5. Trigger nginx reload: The controller automatically reloads nginx with the new configuration, causing the injected directives to take effect within the controller pod.
6. Achieve code execution and Secret exfiltration: The injected configuration executes arbitrary commands in the controller's context. The attacker can then read Kubernetes Secrets accessible to the controller (cluster-wide in default installations) and exfiltrate them to an external endpoint (GitHub Advisory, Kubernetes Issue).

• Kubernetes API Logs: Audit log entries showing creation or modification of Ingress resources with unusual or encoded content in the rules.http.paths.path field, particularly containing nginx directives, semicolons, or newline characters.
• ingress-nginx Controller Logs: Unexpected nginx configuration reload events; error messages or warnings related to configuration parsing; unusual nginx -t test output in controller logs.
• File System (Controller Pod): Unexpected or modified nginx configuration files in /etc/nginx/ within the controller pod; presence of scripts or binaries not part of the standard image.
• Network: Outbound connections from the ingress-nginx controller pod to unexpected external IP addresses or domains, particularly over non-standard ports.
• Process Behavior: Unusual child processes spawned by the nginx master process inside the controller pod (e.g., shell interpreters, curl, wget).
• Kubernetes Secrets Access: Audit logs showing the ingress-nginx service account accessing Secrets in namespaces beyond its normal operational scope (Kubernetes Issue).

Upgrade ingress-nginx to v1.13.7 or v1.14.3 (or any later version), which contain the fix for this vulnerability (GitHub Advisory, Kubernetes Issue). As a pre-upgrade workaround, deploy a validating admission controller (e.g., OPA/Gatekeeper or Kyverno) to reject Ingress resources that use the ImplementationSpecific path type or contain suspicious characters in the path field. Additionally, restrict Ingress creation/modification permissions via RBAC to only trusted users and namespaces, and consider limiting the ingress-nginx service account's access to Secrets using Kubernetes RBAC to reduce the blast radius of exploitation.

The vulnerability received broad coverage across security media outlets including GBHackers, CyberSecurityNews, CSO Online, and eSecurity Planet, with articles highlighting the cluster-wide Secret exposure risk (GBHackers, CSO Online). The Kubernetes security community discussed the issue on the official Kubernetes forum and oss-security mailing list (Kubernetes Forum, oss-security). Notably, the disclosure coincided with broader discussions about the retirement of ingress-nginx as a Kubernetes project, with Datadog Security Labs and others recommending migration to the Gateway API as a longer-term remediation strategy (Datadog Security Labs). runZero and Sysdig also published detection guidance for the vulnerability (runZero, Sysdig).