editorially independent. We may make money when you click on links
to our partners.
Learn More
A recently disclosed vulnerability in ingress-nginx may allow authenticated attackers to execute code and access Kubernetes Secrets in affected clusters.
The vulnerability could “… lead to arbitrary code execution in the context of the ingress-nginx controller, and disclosure of Secrets accessible to the controller,” said Kubernetes researchers.
Inside the Ingress-Nginx Security Vulnerability
Ingress controllers sit at the edge of Kubernetes clusters, where they manage incoming traffic and route requests to internal services.
Because ingress-nginx often operates with elevated privileges, vulnerabilities in this component can have a disproportionate impact.
In many default deployments, the ingress-nginx controller has permission to read Secrets across the entire cluster, meaning a single successful exploit could expose credentials, tokens, or configuration data used by multiple applications.
The vulnerability, tracked as CVE-2026-24512, is a configuration injection issue tied to the rules.http.paths.path field of Kubernetes Ingress resources.
Improper validation of this field allows an attacker to supply specially crafted values that are injected directly into the nginx configuration generated by ingress-nginx.
This behavior breaks the assumption that Ingress definitions are safely translated into server configuration.
An attacker with permission to create or modify Ingress resources can exploit this flaw to inject arbitrary nginx directives.
In practice, this enables arbitrary code execution within the context of the ingress-nginx controller, allowing the attacker to run commands inside the controller pod.
Although authentication is required, the level of access needed is relatively low, which increases risk in environments where developers or service accounts have permission to manage Ingress resources.
The vulnerability is remotely exploitable over the network, has low attack complexity, and does not require user interaction.
In addition to code execution, successful exploitation can result in unauthorized access to Kubernetes Secrets that the controller is allowed to read.
Because ingress-nginx often has cluster-wide Secret access by default, the potential blast radius extends beyond a single namespace and can affect the entire cluster.
CVE-2026-24512 affects multiple ingress-nginx releases, including all versions earlier than v1.13.7 and v1.14.3. The vulnerability has been resolved in ingress-nginx versions 1.13.7, 1.14.3, and all later releases.
At the time of disclosure, there is no information that the vulnerability is being actively exploited in the wild.
Reducing Risk From Ingress Vulnerabilities
Upgrading remains the primary remediation, but additional controls can help reduce risk during patch rollout and improve overall cluster security.
The measures below focus on reducing exposure, tightening permissions, and improving visibility into ingress activity.
- Patch ingress-nginx to version 1.13.7, 1.14.3, or later to fully remediate the vulnerability.
- Deploy a validating admission controller to block Ingress resources using the ImplementationSpecific path type if immediate upgrades are not possible.
- Restrict permissions to create or modify Ingress resources and reduce ingress-nginx RBAC access to only required namespaces and Secrets.
- Monitor Kubernetes audit logs and ingress-nginx configuration changes for suspicious or malformed path values and unexpected updates.
- Limit blast radius by applying network policies and namespace isolation to ingress-nginx deployments.
- Use runtime security monitoring to detect anomalous behavior within ingress-nginx controller pods, such as unexpected process execution or file access.
- Prepare for containment and recovery by retaining Kubernetes audit data and regularly testing incident response plans that include ingress and controller compromise scenarios.
These measures help limit the blast radius of an ingress compromise and strengthen Kubernetes resilience.
Ingress Security Matters
This vulnerability highlights the security considerations associated with highly privileged Kubernetes components at the cluster edge.
While timely upgrades are important, pairing them with tighter access controls, improved monitoring, and tested response processes can help limit impact.
Incorporating ingress security into a broader resilience strategy supports more consistent protection over time.
The focus on limiting privileges and validating access mirrors the core principles of zero-trust.
