Traefik EUVD-2026-75538

Exploitation requires three concurrent non-default conditions: (1) Traefik version 3.2.0 through 3.7.12 with at least one of aliasHeadersStrategy, underscoreHeadersStrategy, or forwardedHeaders protection configured on the affected route; (2) a retry or buffering middleware present in the routing chain for that route - this is the specific Traefik middleware that reads the request body and thereby populates req.Trailer before the proxy clones the request to the backend; and (3) a backend application that merges HTTP trailer fields into its header namespace, causing it to treat the smuggled trailer value as a legitimate header. Default Traefik configurations that lack retry or buffering middleware are not vulnerable because req.Trailer is never populated in the non-buffered path. The attacker requires only unauthenticated network access to Traefik; no credentials or session tokens are needed.

The CVSS 4.0 vector (AV:N/AC:H/PR:N/UI:N, SC:H/SI:H) correctly identifies this as network-exploitable with no authentication requirement, but accurately constrains it to high complexity: exploitation requires both a body-buffering middleware (retry or buffering) active on the targeted route and a backend that merges trailer fields into its header namespace - neither condition is present in a default Traefik deployment. The subsequent-system impact is rated high for confidentiality and integrity because spoofed X-Forwarded-For, X-Real-IP, or identity headers can cause backends to grant unauthorized resource access or impersonate users, with effects that scale directly with backend sensitivity. No EPSS score is present in the input data. There is no CISA KEV listing and no public exploit code identified at time of analysis, so real-world exploitation appears limited to targeted scenarios rather than broad automated scanning. Organizations running Traefik 3.2.0-3.7.12 with retry or buffering middleware in front of backends that consume forwarding headers should treat this as a meaningful priority; multi-tenant deployments or those relying on X-Forwarded-User or similar headers for backend authorization face the highest realistic risk.

An attacker sends an HTTP/1.1 chunked POST request to a Traefik endpoint protected by forwardedHeaders with a sensitive name such as X-Forwarded-User embedded as a chunked trailer field rather than a standard header. Traefik's sanitization middleware removes or rejects the corresponding entry in req.Header but never inspects req.Trailer, so when the configured retry middleware buffers the response body, the trailer value becomes accessible in Go's request object. The backend receives the forwarded request, merges the trailer into its header namespace, and acts on the attacker-supplied identity value as if Traefik had verified and forwarded it, potentially granting unauthorized access or allowing full user impersonation.