Traefik’s ForwardAuth Pool Can Carry Another User’s Identity
Traefik’s ForwardAuth middleware can let an unrelated client inherit another user’s identity when its authentication service uses connection-bound authentication. The maintainer’s 21 October advisory covers a different connection pool from the backend-proxy flaws fixed earlier in the year. Installing those earlier corrections does not establish that this authentication path is protected.
The current advisory, GHSA-hrpp-p4fc-wwf8, rates the issue High, with a CVSS 4.0 score of 7.0. It lists 2.11.60 and 3.7.16 as the fixed releases. Those are the correction’s starting points, rather than a claim that they are the newest available versions or that every Traefik deployment has this exposure.
The identity is attached to the authentication connection
ForwardAuth sends a separate request to an authentication service before deciding whether a visitor should reach the application. A connection-bound scheme, such as NTLM or SPNEGO/Kerberos Negotiate, can associate the authenticated user with a persistent connection to that service. The advisory gives IIS Windows Authentication as an example.
The vulnerable middleware shares its authentication-server connection pool across clients. After one user has authenticated, a request for a different visitor can reuse the already authenticated connection. The authentication service can then return success with the first user’s identity. Traefik passes the identity onward through authResponseHeaders, allowing the unrelated visitor to reach the backend as that user.
The visitor does not need the victim’s credentials. The deployment still needs the relevant connection-bound authentication arrangement. A successful login through an ordinary per-request authentication mechanism is not, on its own, evidence of this flaw. In the 3.7 line, the advisory also includes external authentication through the Kubernetes Ingress NGINX provider’s auth-url annotation.
Check the authentication pool as well as the backend pool
Our earlier Traefik report examined an HTTP/3 backend connection-isolation failure. That report’s reproduction and release matrix concern that earlier vulnerability. The October advisory explicitly distinguishes four predecessor advisories that isolated connection-bound authentication on backend proxy paths. Its correction applies isolation per frontend connection to the authentication server instead.
That distinction changes the inventory question. Identify the middleware and authentication provider actually used by each route, the authentication scheme at that service, and the running Traefik version. Checking only whether a backend uses NTLM, or only whether an earlier HTTP/3 fix was installed, leaves the separate authentication request path unanswered. The October advisory does not make HTTP/3 a prerequisite for this issue.
The fixed releases preceded the public advisory
The release pages for 2.11.60 and 3.7.16 are dated 20 October. Both name the ForwardAuth correction; the latter also names the ingress-nginx auth-url change. The public advisory followed on 21 October.
For the v2 package, the affected range is 2.11.59 and earlier. For v3, it is 3.0.0 through 3.7.15. The maintainer says the 3.0 through 3.6 lines are end of life and will not receive a correction on their own line. Plan a supported migration and application checks rather than waiting for an old-line patch or treating one fixed version as a support guarantee.
Verify separation without declaring the environment clean
BlackTree recommends treating the maintenance result and any investigation as separate tasks. Confirm the actual running replacement after the rollout, then use an authorised test environment to verify that separate frontend clients do not inherit the same authenticated identity. Cover the applicable ForwardAuth and ingress-nginx paths, not just a normal successful login. The sources do not establish that a particular customer has deployed or tested the correction.
Preserve and correlate frontend request identifiers, client connections, authentication decisions and backend actions where those records exist. A backend username alone may describe the inherited identity, so it cannot establish which visitor initiated an action. The advisory describes the vulnerability and its conditions without reporting a compromised customer deployment. That absence of an incident report is not an all-clear for an exposed installation.
