NGINX Ingress Controller EUVD-2026-101118

Exploitation requires the NGINX Ingress Controller to be configured with the ExternalAuth policy or Ingress external authentication (the NGINX auth_request directive); deployments not using external authentication are not exposed. Given the configuration, no further prerequisites apply: the CVSS 4.0 vector (AV:N/AC:L/PR:N/UI:N) indicates remote, low-complexity, unauthenticated exploitation with no user interaction by sending crafted X-Forwarded-Prefix, X-Forwarded-URI, X-Original-URI, or X-Forwarded-Method headers. The primary limiting factor is this non-default dependency on external auth being enabled; the impact is also bounded to the data plane (no control plane exposure per the advisory) and to confidentiality/access rather than integrity or availability.

This is a credible, actionable priority rather than a high-CVSS-but-low-real-risk issue, though its reach is gated by configuration. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) describes a network-reachable, low-complexity, unauthenticated attack requiring no user interaction, with high confidentiality impact (VC:H) and no integrity/availability impact (VI:N/VA:N) - consistent with an authentication/authorization bypass (CWE-290) granting unauthorized read access to protected paths. No EPSS score, CISA KEV listing, or public POC was provided in the input, so exploitation probability signals are absent; there is no public exploit identified at time of analysis and no evidence of active exploitation. The gap between a severe, easy-to-exploit CVSS profile and the absence of KEV/POC/EPSS data means risk hinges on exposure: only deployments using the ExternalAuth policy or Ingress external authentication are affected, so organizations relying on NGINX Ingress Controller's external auth as an access-control boundary should treat this as urgent, while those not using external auth are unaffected. Note the input provides only a CVSS 4.0 vector and no 3.1 vector or EPSS - remediation prioritization should not wait on those missing signals given the unauthenticated network vector.

An unauthenticated remote attacker sends an HTTP request to an NGINX Ingress Controller fronting an application protected by external authentication, injecting spoofed X-Forwarded-Prefix, X-Forwarded-URI, X-Original-URI, or X-Forwarded-Method headers. Because these client-supplied headers are forwarded unsanitized into the internal auth_request subrequest, the external authentication provider evaluates attacker-controlled path/method attributes and authorizes access to a protected resource the attacker should not reach. No public exploit code was identified at time of analysis, but the technique is straightforward header manipulation requiring only network access.