If you run Kubernetes in production and use Ingress-Nginx — and statistically, you probably do — drop what you are doing and check your version. Multiple critical vulnerabilities disclosed under CVE-2026-24512, CVE-2026-24513, and CVE-2026-24514 affect the Ingress-Nginx controller, with CVSS scores reaching 8.8. Maintenance for older version branches ceased in March 2026, meaning there will be no patches for legacy installations. The remediation path is clear: upgrade to v1.13.7 or v1.14.3 and above immediately. Here is what you need to know about the technical details, the attack surface, and the broader implications for Kubernetes ingress security.
The Vulnerabilities in Detail
CVE-2026-24512 is the headline vulnerability. It affects the admission webhook component of the Ingress-Nginx controller, which validates and mutates Ingress resource configurations before they are applied to the cluster. The flaw allows an attacker who can create or modify Ingress objects — a permission commonly granted to developers and CI/CD pipelines — to inject arbitrary Nginx configuration directives through specially crafted annotation values. Because the admission webhook processes these annotations server-side before sanitization, the injected directives are written directly into the Nginx configuration and executed when the controller reloads.
The practical impact is severe. An attacker can achieve remote code execution within the Ingress-Nginx controller pod, which typically has access to TLS secrets for every domain the cluster serves. From there, lateral movement to other cluster resources becomes straightforward, particularly if the controller runs with overly permissive service account credentials — a common misconfiguration.
CVE-2026-24513 (CVSS 8.8) targets a related but distinct attack vector in the Nginx configuration template rendering engine. It enables path traversal through manipulated Ingress path specifications, allowing an attacker to read arbitrary files from the controller pod filesystem, including mounted secrets and service account tokens. CVE-2026-24514 compounds the risk by allowing denial-of-service through malformed annotation values that cause the Nginx configuration parser to enter an infinite loop, effectively taking down ingress for the entire cluster.
Why Ingress Controllers Are High-Value Targets
Ingress controllers occupy a uniquely privileged position in Kubernetes architecture. They sit at the network boundary, terminating TLS for external traffic and routing requests to internal services. By necessity, they have access to TLS certificates and private keys for every domain they serve. They typically run with network access to every service namespace. And they process untrusted input — HTTP requests from the internet — by design.
This combination of privilege and exposure makes ingress controllers among the highest-value targets in a Kubernetes cluster. A compromised ingress controller can intercept and modify all HTTP traffic entering the cluster, steal TLS private keys enabling man-in-the-middle attacks on any served domain, and potentially pivot to the Kubernetes API server using mounted service account tokens. Security researchers have increasingly focused on ingress controllers as an attack vector, and the discovery of these CVEs is part of that broader trend.
Affected Versions and Remediation
All Ingress-Nginx controller versions prior to v1.13.7 in the 1.13.x branch and prior to v1.14.3 in the 1.14.x branch are affected. Critically, the 1.12.x branch and all earlier version lines reached end of maintenance in March 2026 and will not receive patches. Organizations running these legacy versions must upgrade to a supported branch — there is no alternative.
The upgrade process for Ingress-Nginx is well-documented but requires careful planning in production environments. The controller manages Nginx configuration state that affects live traffic routing, so a botched upgrade can cause downtime. The recommended approach is to deploy the new controller version alongside the existing one using a canary strategy, validate that traffic routing works correctly, and then switch over. Helm chart users should update to the corresponding chart version and review the changelog for any breaking changes in configuration semantics.
As an immediate mitigation for organizations that cannot upgrade instantly, restrict who can create and modify Ingress resources using RBAC. The primary attack vector requires the ability to create Ingress objects with arbitrary annotations, so limiting this permission to trusted automation and senior operators reduces the attack surface. Additionally, consider enabling the controller admission webhook in strict mode, which rejects Ingress resources with unknown annotations rather than passing them through.
Defense-in-Depth for Ingress Security
These vulnerabilities underscore the need for layered security around Kubernetes ingress. No single control is sufficient. Network policies should restrict which pods the ingress controller can communicate with — it needs to reach backend services, but it should not have unrestricted cluster-wide network access. Pod security standards should ensure the controller runs as a non-root user with a read-only root filesystem where possible. Secret access should be scoped — the controller should only mount TLS secrets for the domains it actually serves, not have blanket access to all secrets in the namespace.
Runtime security tools like Falco or Tetragon can detect anomalous behavior in the ingress controller pod — shell execution, unexpected network connections, or file access patterns that deviate from the normal controller operation. These tools provide a detection layer that catches exploitation even when prevention fails.
The Bigger Picture
The Ingress-Nginx vulnerabilities are a reminder that Kubernetes security is not a destination but a continuous process. The platform surface area is enormous, the pace of change is relentless, and the components that matter most — ingress controllers, API servers, etcd, kubelet — are precisely the ones that attackers target. The cessation of maintenance for older Ingress-Nginx versions is particularly concerning because many organizations run version-pinned infrastructure that lags behind upstream releases by months or years.
If your organization treats Kubernetes component upgrades as optional or low-priority maintenance, these CVEs should prompt a reassessment. The window between vulnerability disclosure and active exploitation continues to shrink. For internet-facing components like ingress controllers, that window may be days, not weeks. Patch now, review your ingress RBAC policies, implement runtime detection, and put a process in place to ensure you never fall this far behind on security updates again.