Description

A security issue was discovered in ingress-nginx where a user with permission to create an Ingress may be able to cause denial of service of the ingress-nginx data plane, or possibly redirect traffic from other Ingresses. Kubernetes clusters are only affected if they are using ingress-nginx. Due to a missing check, the mirror-target Ingress annotation can be used to target an unauthenticated configuration API within the ingress-nginx controller, allowing write commands to be submitted. Corrupting the data within that configuration API results in all traffic through ingress-nginx being dropped until an Ingress configuration change or a controller restart causes the data to be recreated correctly. In principle, this write access could also be used to redirect traffic from other Ingresses controlled by the same ingress-nginx instance. In practice, there is negligible additional risk: such redirection would require privileged information about internal ingress-nginx state, and users can already redirect traffic from other Ingresses controlled by the same ingress-nginx anyway.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "2.7",
  "pubDate": "2026-11-05T19:17:10.690Z",
  "pubdate": "2026-11-05T19:17:10.690Z",
  "executiveSummary": "A critical security vulnerability exists within the ingress-nginx controller, stemming from improper validation of Ingress annotations. This flaw allows an authenticated user with permissions to create or modify Ingress objects to interact with the internal configuration API of the controller.\nThe vulnerability is primarily classified as an injection-style issue where the 'mirror-target' annotation is misused to send unauthorized write commands to the ingress-nginx configuration interface. Successful exploitation results in a Denial of Service (DoS) for the entire ingress-nginx data plane, as the corruption of configuration data causes the controller to drop traffic across all hosted Ingresses.\nWhile the architecture theoretically permits traffic redirection by manipulating internal state, the primary impact is service instability. The risk is significant for multi-tenant Kubernetes environments where ingress-nginx is shared across various namespaces or users. Exploitation requires the ability to define or modify an Ingress object within the cluster. Because the target API is unauthenticated internally, the controller fails to distinguish between legitimate configuration updates and malicious injections via annotation parameters.",
  "technicalDetails": "The root cause of this vulnerability is a missing validation check on the 'mirror-target' Ingress annotation utilized by the ingress-nginx controller. The controller processes this annotation to determine traffic mirroring behavior, but fails to sanitize or restrict the input when communicating with its internal configuration API.\nThe attack flow begins when an attacker, possessing the authority to create or update Ingress resources, injects a crafted 'mirror-target' annotation. The ingress-nginx controller interprets this annotation and subsequently issues write commands to its internal configuration management interface. Because this internal API lacks requisite authentication and authorization checks for requests originating from the ingress-nginx processing logic, the attacker can effectively force the controller to commit arbitrary or malformed data into its own configuration state.\nUpon receiving the malicious input, the ingress-nginx controller overwrites or corrupts the active configuration data. The immediate post-exploitation impact is the disruption of the data plane; all traffic routed through the affected ingress-nginx instance is dropped. This state persists until the controller either receives a legitimate configuration update that overwrites the corrupted state or undergoes a full restart to reload the configuration from the Kubernetes API server.\nBeyond simple Denial of Service, the vulnerability exposes the internal mechanism responsible for request routing. While the report notes that arbitrary traffic redirection carries significant complexity—requiring deep internal knowledge of the ingress-nginx state—the capability for a user to redirect traffic belonging to other Ingresses within the same instance is technically present through this write primitive. The lack of strict boundary enforcement within the internal API facilitates this lateral movement across managed routes.\nThe vulnerability is inherent to the logic processing the 'mirror-target' annotation. Consequently, all Kubernetes clusters utilizing ingress-nginx are potentially exposed if the ingress-nginx controller is reachable and active. The attack does not require network-level exploitability beyond the ability to interact with the Kubernetes API to submit an Ingress resource. The vulnerability essentially transforms a legitimate configuration mechanism into a vector for state corruption."
}