Kubernetes ingress-nginx rewrite-target configuration injection enables controller code execution

A security issue was discovered in ingress-nginx where the nginx.ingress.kubernetes.io/rewrite-target Ingress annotation can be used to inject configuration into nginx. This can lead to arbitrary code execution in the context of the ingress-nginx controller, and disclosure of Secrets accessible to the controller. (Note that in the default installation, the controller can access all Secrets cluster-wide.)

Kubernetes ingress-nginx is marked affected by default within these semver boundaries:

• Versions less than 1.13.8.
• Versions less than 1.14.4.
• Versions less than 1.15.0.

These boundaries represent the parallel release lines listed by the advisory. The status of a release line or build not represented above should not be inferred from these boundaries alone.

The flaw is in how ingress-nginx processes the nginx.ingress.kubernetes.io/rewrite-target annotation on an Ingress resource. Attacker-controlled content can reach nginx configuration without sufficient validation, creating an improper input validation weakness that permits configuration injection. An attacker needs permission to create or modify an Ingress in a cluster running ingress-nginx; when the controller processes that resource, arbitrary code may execute in the context of the ingress-nginx controller. The result can also include reading Secrets accessible to the controller, and the default installation may grant access to all Secrets cluster-wide. The advisory states that suspicious data in the rules.http.paths.path field may indicate an exploitation attempt. The exact parser or internal function responsible for configuration generation is not established by the advisory.

The supplied assessment describes a network-reachable attack requiring low privileges, low complexity, and no end-user interaction. The maintainer explains that the practical prerequisite is an account permitted to create an Ingress, while the resulting privilege escalation depends on cluster configuration. The record marks public exploit material as available, and a public training lab contains components intended to support exploitation. This confirms public exploit availability, not exploitation of any particular system. The known_exploited and ransomware_campaign fields do not establish a confirmed status; their absence is not evidence that exploitation has never occurred.

The flaw can provide arbitrary code execution in the ingress-nginx controller context and access to Secrets available to that controller. In privilege terms, the impact may begin with a principal that can create or modify an Ingress and extend to the controller and resources within its permission scope. The maintainer notes that the result could approach cluster-admin access depending on cluster configuration, but that level of access is not guaranteed in every deployment. Ingress configuration integrity, Secret confidentiality, and potentially service availability can be affected. The advisory does not define a fixed blast radius beyond the controller's effective permissions.

Data confidentiality: Secrets readable by the ingress-nginx controller may be disclosed; in the default installation, the advisory describes that access as cluster-wide.

Integrity and control: Code execution in the controller context may allow changes to ingress behavior and to resources within that context's permissions.

Operations: Controller compromise could affect ingress routing or service availability, although the advisory does not describe a specific outage scenario.

Blast radius: The practical impact depends on controller RBAC and deployment configuration; not every cluster grants the same Secret access.

1. Upgrade ingress-nginx to the fixed release corresponding to the deployed branch: 1.13.8, 1.14.4, or 1.15.0.
2. If an upgrade cannot be completed immediately, use admission control to block the nginx.ingress.kubernetes.io/rewrite-target annotation, as recommended by the advisory.
3. Inventory all clusters, controller deployments, and Ingress resources to ensure that affected releases and suspicious resources are not left during the transition.
4. If exploitation evidence is found, treat Secrets within the controller's access scope as potentially exposed, activate incident response, and contact Kubernetes security as directed by the advisory.

1. Check whether the cluster runs ingress-nginx using the selector published by the advisory: kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx.
2. Inventory the deployed ingress-nginx controller image or release in every cluster and compare it with the affected boundaries in the advisory.
3. Review Ingress resources containing the nginx.ingress.kubernetes.io/rewrite-target annotation, with particular attention to unusual data in rules.http.paths.path.
4. Review Kubernetes audit logs to identify principals that created or modified relevant Ingress resources. This follows the published attack prerequisite and is not a standalone IOC.
5. Use controller logs and audit telemetry as precautionary monitoring for suspicious changes. The absence of suspicious records does not prove that a deployment is safe.