NGINX Ingress Controller CVE-2026-77180

Exploitation requires an authenticated Kubernetes principal - user account, service account, or automation credential - with Kubernetes RBAC write permission specifically on Ingress resources (verbs: create, update, patch) in at least one namespace where NGINX Ingress Controller operates. The vulnerability is triggered only when Ingress annotations are present and processed by the controller; it is not exploitable from the NGINX data plane or by external unauthenticated actors. Key limiting factors: the requirement for Kubernetes API authentication with Ingress write permissions significantly constrains the attacker pool to trusted insiders, compromised CI/CD pipelines, or service accounts with overly broad RBAC bindings. Clusters enforcing strict least-privilege RBAC with Ingress write access limited to cluster administrators are substantially less exposed.

The CVSS 4.0 score of 8.7 (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N) accurately captures the risk profile: low access complexity once the required Kubernetes RBAC permissions are held, with high confidentiality and integrity impact on the Ingress Controller's control plane. The bounded scope - SC:N/SI:N/SA:N confirming no subsequent-system propagation - is an important moderating factor; downstream workloads behind the ingress are not directly compromised, though NGINX routing manipulation could disrupt service availability or redirect traffic. No public exploit code has been identified and the vulnerability is absent from CISA KEV, meaning active exploitation is currently unconfirmed. The realistic threat population is narrow: insiders, compromised CI/CD service accounts, or developers granted Ingress write permissions in shared Kubernetes clusters represent the primary risk vectors. Organizations running multi-tenant clusters with loosely scoped RBAC on Ingress resources should treat patching as urgent given the low complexity of exploitation once access conditions are met.

An attacker holding a Kubernetes service account credential with RBAC write permission on Ingress resources in any namespace submits a crafted Ingress object whose annotation values contain embedded newlines and NGINX directives - for example, injecting a directive to include an attacker-writable file path or disable a location block. When NGINX Ingress Controller next regenerates its nginx.conf, the injected directives are included verbatim, causing NGINX to load an attacker-influenced configuration that may redirect traffic, expose files accessible to the NGINX process, or disable ingress routing. No public proof-of-concept has been identified, but the injection technique is well understood by anyone familiar with NGINX configuration syntax and Kubernetes annotation handling.