CVE-2026-94197: NGINX Ingress Controller ExternalAuth header spoofing bypass

What it is

NGINX Ingress Controller (NIC) can hand authentication decisions to an external service. When it does, it sends that service an internal auth_request subrequest. On affected versions, the headers X-Forwarded-Prefix, X-Forwarded-URI, X-Original-URI and X-Forwarded-Method from the client are passed into that subrequest unsanitized.

An unauthenticated attacker over the network can therefore forge the path and method the auth provider sees. If the provider makes its decision from those values, the attacker may reach paths that should be protected. The CVE record rates the impact as confidentiality only (CVSS 3.1 of 7.5, CVSS 4.0 of 8.7) and calls it a “data plane issue only.”

The weakness is CWE-290, authentication bypass by spoofing. The record does not report exploitation, a public proof of concept or a CISA KEV listing; see the open points in the editor checks.

Am I affected?

You’re affected if you run NGINX Ingress Controller 5.5.0 up to, but not including, 5.7.0 and use the ExternalAuth policy or Ingress external authentication. The exposure depends on your auth backend: it matters if the backend trusts the forwarded path or method headers.

F5 did not evaluate versions that have reached End of Technical Support. Treat them as unaffected only after you confirm with F5.

To check: find the NIC version in your running controller image, then look for ExternalAuth policies and Ingress resources that use external authentication. Then check whether your auth backend decides based on X-Forwarded-* or X-Original-* values.

What to do

1. Upgrade NGINX Ingress Controller to 5.7.0 or later.
2. If you can’t upgrade yet, change the auth backend so it ignores client-supplied X-Forwarded-* and X-Original-* headers, or so it evaluates only session tokens and not forwarded paths. This is F5’s workaround. Test it first: backends that rely on those headers for routing rules will change behavior.
3. If a vulnerable controller was reachable from the internet, review access to protected paths from before the upgrade (see Detection). Rotate secrets that those paths exposed if you find unexpected access.

Detection

F5 and the sources we checked have published no exploitation indicators. What you can look for:

• Requests with client-set X-Forwarded-Prefix, X-Forwarded-URI, X-Original-URI or X-Forwarded-Method arriving at the controller from outside. Your edge proxy or load balancer should normally set these, not clients.
• Successful responses on protected paths from clients that never completed authentication with your provider.
• Auth backend logs showing path or method values that don’t match the request the controller actually received.