CVE-2026-54764

Traefik is an HTTP reverse proxy and load balancer. Prior to v2.11.51, v3.6.22, and v3.7.6, Traefik's ForwardAuth middleware, even when configured with trustForwardHeader: false, derives the X-Forwarded-Port header sent to the authentication service from the original incoming request instead of the sanitized forwarded request. As a result, an unauthenticated remote attacker can inject an X-Forwarded-Proto: https header over a plain HTTP connection and cause Traefik to forward X-Forwarded-Port: 443 to the authentication service, bypassing port-based authorization checks. This issue is fixed in versions v2.11.51, v3.6.22, and v3.7.6.

Traefik is an HTTP reverse proxy and load balancer. Prior to v2.11.51, v3.6.22, and v3.7.6, Traefik's ForwardAuth middleware, even when configured with trustForwardHeader: false, derives the X-Forwarded-Port header sent to the authentication service from the original incoming request instead of the sanitized forwarded request. As a result, an unauthenticated remote attacker can inject an X-Forwarded-Proto: https header over a plain HTTP connection and cause Traefik to forward X-Forwarded-Port: 443 to the authentication service, bypassing port-based authorization checks. This issue is fixed in versions v2.11.51, v3.6.22, and v3.7.6.

Summary

There is a medium severity vulnerability in Traefik's ForwardAuth middleware. Even when configured with trustForwardHeader: false, Traefik derives the X-Forwarded-Port header sent to the authentication service from the original incoming request instead of the sanitized forwarded request. As a result, an unauthenticated remote attacker can inject an X-Forwarded-Proto: https header over a plain HTTP connection and cause Traefik to forward X-Forwarded-Port: 443 to the auth service, bypassing port-based authorization checks. This is a regression of the incomplete fix for GHSA-6384-m2mw-rf54, which addressed the X-Forwarded-Proto and X-Forwarded-Prefix spoofing vectors but missed the X-Forwarded-Port vector.

Patches

• https://github.com/traefik/traefik/releases/tag/v2.11.51
• https://github.com/traefik/traefik/releases/tag/v3.6.22
• https://github.com/traefik/traefik/releases/tag/v3.7.6

For more information

If you have any questions or comments about this advisory, please open an issue.

<details> <summary>Original Description</summary>

Summary

The ForwardAuth middleware, even when configured with trustForwardHeader: false, still derives the X-Forwarded-Port header sent to the authentication service by reading the attacker-controlled X-Forwarded-Proto header from the original incoming request. This allows an unauthenticated remote attacker to cause Traefik to forward X-Forwarded-Port: 443 to the auth service on a plain HTTP connection, creating an inconsistency that can bypass port-based authorization checks.

Details

The fix introduced in commit 5e1de2258 (released as part of the April 2026 security advisory GHSA-6384-m2mw-rf54) correctly strips all X-Forwarded-* headers from the forwarded auth request when trustForwardHeader=false, and reconstructs X-Forwarded-Proto from the actual TLS state of the connection (req.TLS).

However, the reconstruction of X-Forwarded-Port is delegated to the helper forwardedPort(req) which receives the original request (req) rather than the sanitized forward request (forwardReq):

// pkg/middlewares/auth/forward.go – writeHeader()
if !trustForwardHeader {
    forwardedheaders.DeleteXForwardedHeaders(forwardReq.Header) // strips all X-Fwd-* from forwardReq
}
// ...
if _, ok := forwardReq.Header[forwardedheaders.XForwardedPort]; !ok {
    forwardReq.Header.Set(forwardedheaders.XForwardedPort, forwardedPort(req)) // ← req = ORIGINAL
}

// pkg/middlewares/auth/forward.go – forwardedPort()
func forwardedPort(req *http.Request) string {
    if _, port, err := net.SplitHostPort(req.Host); err == nil && port != "" {
        return port
    }
    // Reads attacker-controlled header on the ORIGINAL request:
    if req.Header.Get(forwardedheaders.XForwardedProto) == "https" || ... {
        return "443"
    }
    if req.TLS != nil {
        return "443"
    }
    return "80"
}

Result when trustForwardHeader=false and attacker sends X-Forwarded-Proto: https
on a plain HTTP connection:

┌──────────────────────────────────┬──────────┬────────┐
│ Header forwarded to auth service │ Expected │ Actual │
├──────────────────────────────────┼──────────┼────────┤
│ X-Forwarded-Proto                │ http     │ http ✓ │
├──────────────────────────────────┼──────────┼────────┤
│ X-Forwarded-Port                 │ 80       │ 443 ✗  │
…

Traefik is an HTTP reverse proxy and load balancer. Prior to v2.11.51, v3.6.22, and v3.7.6, Traefik's ForwardAuth middleware, even when configured with trustForwardHeader: false, derives the X-Forwarded-Port header sent to the authentication service from the original incoming request instead of the sanitized forwarded request. As a result, an unauthenticated remote attacker can inject an X-Forwarded-Proto: https header over a plain HTTP connection and cause Traefik to forward X-Forwarded-Port: 443 to the authentication service, bypassing port-based authorization checks. This issue is fixed in versions v2.11.51, v3.6.22, and v3.7.6.

Traefik is an HTTP reverse proxy and load balancer. Prior to v2.11.51, v3.6.22, and v3.7.6, Traefik's ForwardAuth middleware, even when configured with trustForwardHeader: false, derives the X-Forwarded-Port header sent to the authentication service from the original incoming request instead of the sanitized forwarded request. As a result, an unauthenticated remote attacker can inject an X-Forwarded-Proto: https header over a plain HTTP connection and cause Traefik to forward X-Forwarded-Port: 443 to the authentication service, bypassing port-based authorization checks. This issue is fixed in versions v2.11.51, v3.6.22, and v3.7.6.

Summary

There is a medium severity vulnerability in Traefik's ForwardAuth middleware. Even when configured with trustForwardHeader: false, Traefik derives the X-Forwarded-Port header sent to the authentication service from the original incoming request instead of the sanitized forwarded request. As a result, an unauthenticated remote attacker can inject an X-Forwarded-Proto: https header over a plain HTTP connection and cause Traefik to forward X-Forwarded-Port: 443 to the auth service, bypassing port-based authorization checks. This is a regression of the incomplete fix for GHSA-6384-m2mw-rf54, which addressed the X-Forwarded-Proto and X-Forwarded-Prefix spoofing vectors but missed the X-Forwarded-Port vector.

Patches

• https://github.com/traefik/traefik/releases/tag/v2.11.51
• https://github.com/traefik/traefik/releases/tag/v3.6.22
• https://github.com/traefik/traefik/releases/tag/v3.7.6

For more information

If you have any questions or comments about this advisory, please open an issue.

<details> <summary>Original Description</summary>

Summary

The ForwardAuth middleware, even when configured with trustForwardHeader: false, still derives the X-Forwarded-Port header sent to the authentication service by reading the attacker-controlled X-Forwarded-Proto header from the original incoming request. This allows an unauthenticated remote attacker to cause Traefik to forward X-Forwarded-Port: 443 to the auth service on a plain HTTP connection, creating an inconsistency that can bypass port-based authorization checks.

Details

The fix introduced in commit 5e1de2258 (released as part of the April 2026 security advisory GHSA-6384-m2mw-rf54) correctly strips all X-Forwarded-* headers from the forwarded auth request when trustForwardHeader=false, and reconstructs X-Forwarded-Proto from the actual TLS state of the connection (req.TLS).

However, the reconstruction of X-Forwarded-Port is delegated to the helper forwardedPort(req) which receives the original request (req) rather than the sanitized forward request (forwardReq):

// pkg/middlewares/auth/forward.go – writeHeader()
if !trustForwardHeader {
    forwardedheaders.DeleteXForwardedHeaders(forwardReq.Header) // strips all X-Fwd-* from forwardReq
}
// ...
if _, ok := forwardReq.Header[forwardedheaders.XForwardedPort]; !ok {
    forwardReq.Header.Set(forwardedheaders.XForwardedPort, forwardedPort(req)) // ← req = ORIGINAL
}

// pkg/middlewares/auth/forward.go – forwardedPort()
func forwardedPort(req *http.Request) string {
    if _, port, err := net.SplitHostPort(req.Host); err == nil && port != "" {
        return port
    }
    // Reads attacker-controlled header on the ORIGINAL request:
    if req.Header.Get(forwardedheaders.XForwardedProto) == "https" || ... {
        return "443"
    }
    if req.TLS != nil {
        return "443"
    }
    return "80"
}

Result when trustForwardHeader=false and attacker sends X-Forwarded-Proto: https
on a plain HTTP connection:

┌──────────────────────────────────┬──────────┬────────┐
│ Header forwarded to auth service │ Expected │ Actual │
├──────────────────────────────────┼──────────┼────────┤
│ X-Forwarded-Proto                │ http     │ http ✓ │
├──────────────────────────────────┼──────────┼────────┤
│ X-Forwarded-Port                 │ 80       │ 443 ✗  │
…