A configuration injection flaw in ingress-nginx lets an authenticated user with Ingress create/update rights execute arbitrary code in the controller and read every Secret the controller can access; by default, all Secrets cluster-wide.
What Is It
CVE-2026-24512 is an input validation weakness (CWE-20) in ingress-nginx, the widely deployed Kubernetes ingress controller. The rules.http.paths.path field of an Ingress object is not sufficiently sanitized before being templated into the controller's generated nginx configuration. An attacker who can create or modify Ingress resources can inject nginx directives directly into the running config, leading to arbitrary code execution in the context of the ingress-nginx controller pod and disclosure of any Kubernetes Secret the controller can read.
Why It Matters
The CVSS v3.1 base score is 8.8 (HIGH), vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Only low privileges are required, namespace-scoped permission to create Ingress resources is enough, and there is no user interaction. In a default ingress-nginx install, the controller's service account can read Secrets across the entire cluster, so successful exploitation effectively hands an attacker every credential, token, and certificate stored as a Secret anywhere in the cluster. This collapses the typical multi-tenant trust boundary in Kubernetes: a single compromised namespace tenant becomes a cluster-wide compromise.
What's Vulnerable
ingress-nginx deployments where untrusted or lower-privileged users have the ability to create or update Ingress objects. The attack surface is the rules.http.paths.path field on the Ingress API. NVD does not publish specific affected version CPEs for this entry; consult the upstream Kubernetes issue tracker for fixed-version detail.
Patch Status
The vulnerability is tracked in Kubernetes issue #136678. NVD lists the record as Deferred. No CISA KEV entry has been published for this CVE at the time of this brief, so there is no confirmed in-the-wild exploitation reporting in KEV. Operators should follow the upstream Kubernetes issue for fix versions and apply the upgrade as soon as it lands; in the interim, tightly restrict who can create or modify Ingress resources in multi-tenant clusters.
Sources
- NVD, CVE-2026-24512: https://nvd.nist.gov/vuln/detail/CVE-2026-24512
- Kubernetes issue #136678: https://github.com/kubernetes/kubernetes/issues/136678