High priorityDisclosed

Advisory · CVE-2026-94197

Spoofed forwarding headers bypass external authentication in NGINX Ingress Controller

An authentication and authorization bypass exists in F5 NGINX Kubernetes Ingress Controller when configured with the ExternalAuth policy or Ingress external authentication: client-supplied X-Forwarded-Prefix, X-Forwarded-URI, X-Original-URI, and X-Forwarded-Method headers are forwarded unsanitized into the internal authentication subrequest, so an unauthenticated remote attacker may spoof request attributes the external authentication provider evaluates and reach protected paths. F5 rates it CVSS 4.0 8.7 (CVSS 3.1 7.5), affecting 5.5.0 before 5.7.0.

Advisory published October 14, 2026Independent summary
Vendor
F5
Product
NGINX Ingress Controller
Identifier / CWE
CVE-2026-94197
CWE-290
Action timing
Immediate
ELI5

Explain it like I’m five

The client gets to fill in the headers the auth check trusts, so the check politely believes whatever it is told.

SIMPLIFIED_ATTACK_PATH03 STEPS
  1. 01Spoofed headers sent

    An unauthenticated attacker sends a request with crafted X-Forwarded-Prefix, X-Forwarded-URI, X-Original-URI, or X-Forwarded-Method headers.

  2. 02Subrequest inherits them

    The controller forwards the headers unsanitized into the internal authentication subrequest.

  3. 03Auth provider spoofed

    The provider evaluates the spoofed attributes and the attacker reaches protected paths.

What happened

F5 disclosed CVE-2026-94197 for NGINX Ingress Controller with the ExternalAuth policy or Ingress external authentication configured. Client-supplied forwarding and original-request headers are forwarded unsanitized into the internal authentication subrequest handled by the auth_request directive, letting an unauthenticated remote attacker spoof the request attributes the external authentication provider evaluates and gain unauthenticated access to protected paths. F5 notes this is a data plane issue only.

F5’s K000162611 lists the affected versions and the fixed builds. Match your deployment to the article before changing anything.

What to do

  1. Inventory every NGINX Ingress Controller deployment, including test, training, and individually managed instances.
  2. Apply the vendor fix or upgrade exactly as directed in the linked vendor bulletin or advisory.
  3. Restrict network access to NGINX Ingress Controller while remediation is underway, especially for internet-facing instances.
  4. Review application and server logs for requests to ExternalAuth-protected paths carrying client-supplied X-Forwarded or X-Original headers, and auth decisions that do not match the original request path.
  5. Check for accounts, content, or configuration created outside normal change processes, and rotate exposed credentials where access cannot be ruled out.
  6. Verify the deployed version or patch level after remediation.

Management note

Header trust is the recurring ingress mistake. Patch the controller, and have your auth provider log what it actually evaluated.