Summary
- Traefik ForwardAuth could reuse an authentication server connection previously associated with another user's identity.
- The vulnerability affects connection-bound authentication, including NTLM and Kerberos Negotiate, rather than every ForwardAuth installation.
- Traefik 2.11.60 and 3.7.16 contain fixes; affected end-of-life 3.0–3.6 branches will not receive separate patches.
Traefik has released security fixes for a vulnerability that could allow an unauthenticated client to access a protected application using another person’s identity when the reverse proxy is configured with particular enterprise authentication systems.
The flaw affects ForwardAuth middleware communicating with an authentication service that uses connection-bound schemes, including NTLM and SPNEGO/Kerberos Negotiate. Traefik disclosed the issue on 21 October in security advisory GHSA-hrpp-p4fc-wwf8.
It has a CVSS v4.0 score of 7.0, classified as high severity. Corrected releases are available in Traefik 2.11.60 and 3.7.16.
The vulnerability arises from the handling of connections between the reverse proxy and its authentication service. It does not establish a general authentication failure affecting every installation of ForwardAuth or every application deployed behind Traefik.
Authentication state crossed a connection boundary
ForwardAuth allows a protected application to delegate authentication decisions to an external service. When a client requests access, Traefik submits an authentication request and evaluates the response before forwarding traffic to the application.
In some deployments, the authentication service also returns identity information that Traefik passes to the protected application through configured response headers.
Applications may use those headers to recognise a user and apply existing permissions. Their security therefore depends on the authentication service accurately identifying the client responsible for the original request.
The disclosed weakness affects authentication schemes in which the user’s authenticated state is associated with a network connection, rather than determined independently for each HTTP request.
NTLM and some uses of Kerberos Negotiate can operate in this way. After the authentication service associates a connection with one user, later activity on that connection may inherit the existing authenticated context.
Traefik’s advisory explains that ForwardAuth used a shared pool of connections to the authentication server. A connection previously authenticated for one client could consequently be reused for a request made by an unrelated client.
Under the affected conditions, the authentication service could return a successful response containing the original user’s identity. Traefik could then forward that identity to the protected application.
The second client would be treated as the first user despite not having authenticated as that person.
The resulting failure concerns the separation of identity between requests. The protected application may continue following its normal access controls while applying them to the wrong user because its authentication information is incorrect.
Windows authentication integrations are particularly relevant
The advisory identifies Microsoft Windows authentication integrations as an example of the affected configuration, including services using IIS Windows Authentication.
Such arrangements may be present in internal applications that rely on existing directory services, enterprise identity infrastructure or integrated sign-in mechanisms.
Those environments can place reverse proxies between users and older applications, using an external authentication service to provide access controls without rewriting the application itself.
Where that integration relies on connection-bound authentication, the proxy must preserve the relationship between the incoming client’s request and the corresponding authenticated connection to the identity service.
The vulnerability undermined that relationship. Its significance depends on what the protected application allows the incorrectly assigned identity to access.
If the original user had privileges unavailable to the unauthenticated client, those permissions could be exposed through the incorrect authentication response.
The advisory does not establish that an attacker can obtain unrestricted administrative control over every affected application. The resulting access remains dependent on the identity inherited and the permissions applied by the backend service.
Traefik also identifies an equivalent condition in version 3.7 when external authentication is configured using the Kubernetes Ingress NGINX provider’s auth-url annotation.
That extends assessment beyond directly configured ForwardAuth middleware to Kubernetes deployments using the affected provider integration.
New correction addresses a different connection pool
The issue is related in mechanism to, but distinct from, vulnerabilities Traefik disclosed earlier in October.
Those previous advisories addressed connection-bound authentication risks involving connections from the proxy to protected backend applications.
The new vulnerability involves connections from Traefik to the separate authentication server.
Both involve the importance of keeping authentication state associated with the correct frontend client, but the relevant connection pools and corrective changes are different.
The 21 October fix applies isolation to the authentication server connection pool so that an authentication context created for one frontend client is not reused for an unrelated client’s request.
Traefik lists version 2.11.59 and earlier supported 2.11 releases as affected. In version 3, the affected range extends from 3.0.0 through 3.7.15.
Versions 3.0 through 3.6 have reached end of life and will not receive individual maintenance corrections. Installations on those branches require migration to a supported corrected release.
For organisations maintaining authentication infrastructure, the version number alone does not determine whether the vulnerable condition exists. The configuration of ForwardAuth, the authentication protocol and the relevant Kubernetes integrations must also be established.
Conversely, the absence of a confirmed incident does not remove the underlying vulnerability where the affected combination is deployed.
The public advisory does not identify exploited organisations or a wider attack campaign. It documents a high-severity route to identity impersonation under specified conditions and identifies the releases containing the correction.
