CVE-2026-94197 in NGINX Ingress Controller
Summary
by MITRE • 10/14/2026
An authentication and authorization bypass vulnerability exists in F5 NGINX Kubernetes Ingress Controller (NIC) 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 routing and method headers are forwarded unsanitized into the internal authentication subrequest (handled by the NGINX auth_request directive). As a result, an unauthenticated, remote attacker may spoof request attributes evaluated by the external authentication provider.
Impact: This vulnerability may allow remote attackers
unauthenticated
access to protected
paths. There is no control plane exposure; this is a data plane issue only.
Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/14/2026
The F5 NGINX Kubernetes Ingress Controller, specifically when configured with the ExternalAuth policy or Ingress external authentication mechanisms, contains a critical security flaw related to improper input validation and sanitization of HTTP headers. This vulnerability stems from the controller's handling of client-supplied routing and method metadata during the request processing lifecycle. When an incoming request is received by the NGINX ingress controller, it often needs to forward specific attributes to an external authentication provider via the auth_request directive. In this process, the controller incorrectly forwards several sensitive headers without adequate sanitization or validation. These headers include X-Forwarded-Prefix, which defines the base path for routing; X-Forwarded-URI and X-Original-URI, which specify the requested resource path; and X-Forwarded-Method, which indicates the HTTP method of the request. By allowing these values to pass through unsanitized into the internal authentication subrequest, the ingress controller effectively allows a remote attacker to manipulate how the external authentication provider interprets the context of the incoming request.
This architectural flaw leads directly to an authentication and authorization bypass scenario. Because the external authentication service relies on these forwarded headers to determine access control decisions, an unauthenticated, remote attacker can craft malicious requests that spoof legitimate request attributes. For instance, by manipulating the X-Forwarded-Prefix or URI headers, an attacker might trick the authentication provider into believing a request is targeting a public resource rather than a protected one, or vice versa, potentially bypassing access controls designed to restrict entry to specific paths. Similarly, altering method-related headers could interfere with authorization logic that depends on HTTP methods for permission checks. The core issue lies in the lack of strict allow-lists or validation routines to ensure that only expected and safe values are propagated to the authentication backend, creating a vector where trust boundaries between the ingress layer and the external auth service are compromised through header injection techniques.
The operational impact of this vulnerability is significant for organizations relying on F5 NGINX Kubernetes Ingress Controller for securing their microservices architecture. Successful exploitation allows unauthenticated remote attackers to gain access to protected paths within applications deployed behind the ingress controller. This constitutes a direct breach of confidentiality and integrity for data residing in these protected endpoints, as sensitive APIs or administrative interfaces may become accessible without proper credentials. It is crucial to note that this vulnerability affects only the data plane; it does not expose the control plane of the Kubernetes cluster or the NGINX configuration itself. Therefore, while an attacker can access specific application resources they should not be able to reach, they do not gain direct administrative control over the underlying infrastructure components such as etcd, kube-apiserver, or the ingress controller's management interface. This distinction limits the blast radius but does not diminish the severity of potential data exfiltration or unauthorized operations within the affected applications.
From a classification perspective, this vulnerability aligns with CWE-287, which describes Improper Authentication, as well as CWE-601, URL Redirection to Untrusted Site (Open Redirect), depending on how the spoofed headers are utilized by downstream services. In terms of offensive security frameworks, this behavior is consistent with ATT&CK technique T1556, specifically Modifying Application Access Control, where an adversary alters authentication mechanisms or access control lists to bypass intended restrictions. The exploitation vector involves sending specially crafted HTTP requests from a remote location over the network, making it accessible via standard web traffic without requiring prior local access or complex setup beyond crafting the malicious headers.
To mitigate this risk, organizations must apply the relevant software patches provided by F5 Networks as soon as possible. Until patching is feasible, defensive measures should focus on hardening the ingress configuration and implementing additional security layers at the network perimeter. It is advisable to configure NGINX or a preceding reverse proxy to strip or validate these specific headers before they reach the authentication subrequest logic. Implementing strict input validation rules that reject any unexpected values for X-Forwarded-Prefix, URI-related headers, and method indicators can prevent header injection attacks. Additionally, deploying Web Application Firewalls with rulesets designed to detect anomalous HTTP header patterns may provide an additional layer of defense against exploitation attempts. Regular security audits and penetration testing focused on authentication bypass vectors are recommended to ensure that such vulnerabilities do not persist in the production environment.