GHSA-5M6W-WVH7-57VM
Vulnerability from github – Published: 2026-04-24 16:32 – Updated: 2026-05-06 21:24Summary
There is a high severity authentication bypass vulnerability in Traefik's ForwardAuth and snippet-based authentication middleware. Traefik's forwarded-header sanitization logic targets only canonical header names (e.g., X-Forwarded-Proto) and does not strip or normalize alias variants that use underscores instead of dashes (e.g., X_Forwarded_Proto). These unsanitized alias headers are forwarded intact to the authentication backend. When the backend normalizes underscore and dash header forms equivalently, an attacker can inject spoofed trust context — such as a trusted scheme or host — through the alias headers and bypass authentication on protected routes without valid credentials.
Patches
- https://github.com/traefik/traefik/releases/tag/v2.11.43
- https://github.com/traefik/traefik/releases/tag/v3.6.14
- https://github.com/traefik/traefik/releases/tag/v3.7.0-rc.2
For more information
If there are any questions or comments about this advisory, please open an issue.
Original Description ### Summary An authentication bypass arises from chaining two bugs: incomplete forwarded-header sanitization at ingress and overly permissive header forwarding in pre-auth subrequests. While canonical `X-Forwarded-*` headers are handled, alias variants (e.g., underscore forms) are neither normalized nor stripped consistently. When downstream auth services normalize these headers, attackers can inject trusted context and bypass authentication on protected routes without credentials. ### Details This issue results from the interaction between forwarded-header handling and auth subrequest construction, creating a trust boundary mismatch. At ingress, Traefik defines a fixed set of canonical forwarded headers (`X-Forwarded-Proto`, `X-Forwarded-For`, etc.): Reference : [`pkg/middlewares/forwardedheaders/forwarded_header.go#L29-L36`](https://github.com/traefik/traefik/blob/174e5d81111d8e9fb3d3c81cf6d22f3e33eb4f78/pkg/middlewares/forwardedheaders/forwarded_header.go#L29-L36)var xHeaders = []string{
xForwardedProto,
xForwardedFor,
xForwardedHost,
xForwardedPort,
This logic focuses exclusively on canonical header names and does not account for alias forms such as `X_Forwarded_Proto`. As a result, while standard headers may be sanitized or rewritten, semantically equivalent variants can pass through unchanged.
During ForwardAuth processing, request headers are copied wholesale into the auth subrequest:
Reference : [`pkg/middlewares/auth/forward.go#L401-L408`](https://github.com/traefik/traefik/blob/174e5d81111d8e9fb3d3c81cf6d22f3e33eb4f78/pkg/middlewares/auth/forward.go#L401-L408)
utils.CopyHeaders(forwardReq.Header, req.Header)
RemoveConnectionHeaders(forwardReq)
utils.RemoveHeaders(forwardReq.Header, hopHeaders...)
This implementation forwards nearly all client-supplied headers to the auth backend, with filtering limited to hop-by-hop headers. There is no normalization or deduplication between canonical and alias header forms, meaning attacker-controlled headers can reach the auth service intact.
A similar pattern exists in snippet-based auth:
Reference : [`pkg/middlewares/ingressnginx/snippet/snippet.go#L574-L581`](https://github.com/traefik/traefik/blob/174e5d81111d8e9fb3d3c81cf6d22f3e33eb4f78/pkg/middlewares/ingressnginx/snippet/snippet.go#L574-L581)
utils.CopyHeaders(forwardReq.Header, req.Header)
RemoveConnectionHeaders(forwardReq)
utils.RemoveHeaders(forwardReq.Header, hopHeaders...)
Again, headers are forwarded without enforcing a consistent trust model or canonicalization.
The vulnerability emerges when the auth backend normalizes header names (e.g., treating `X_Forwarded_Proto` and `X-Forwarded-Proto` equivalently). In that case:
- Traefik sanitizes only canonical headers.
- Alias headers remain attacker-controlled.
- The auth service merges or evaluates these aliases during normalization.
- Trust predicates (e.g., scheme = HTTPS, trusted host) are satisfied using spoofed values.
This allows a single crafted request to simultaneously bypass ingress trust enforcement and satisfy authentication checks, resulting in unauthorized access to protected backends.
### PoC
1. Configure a protected route using ForwardAuth or snippet-based auth, with an auth backend that normalizes header names (underscore ↔ dash).
2. Send a control request (expected: denied):
GET / HTTP/1.1
Host: target.local
User-Agent: poc-control
Connection: close
3. Send an exploit request with alias headers (expected: allowed):
GET /protected HTTP/1.1
Host: app.example.local
X_Forwarded_Proto: https
X_Forwarded_Host: trusted.example
Connection: close
### Impact
This vulnerability allows unauthenticated attackers to bypass authentication at the proxy-to-auth boundary by injecting spoofed trust context through header aliases. In deployments where authorization decisions depend on forwarded headers, attackers can access protected endpoints and interact with backend services as if they were fully authenticated. This effectively undermines ForwardAuth and similar mechanisms, potentially exposing sensitive internal functionality and data.
### Suggested Remediation
1. Strip and regenerate both canonical and alias forms of forwarded headers consistently at ingress and during auth subrequests.
2. Apply a unified normalization policy across all forwarded header families (including RFC7239 and `X-Forwarded-*`).
3. Restrict which headers are forwarded to auth services (prefer explicit allowlists).
4. Add regression tests covering alias normalization inconsistencies across common backend frameworks.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik/v3"
},
"ranges": [
{
"events": [
{
"introduced": "3.7.0-ea.1"
},
{
"fixed": "3.7.0-rc.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik/v3"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0-beta1"
},
{
"fixed": "3.6.14"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.11.43"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.7.34"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-39858"
],
"database_specific": {
"cwe_ids": [
"CWE-290",
"CWE-306"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-24T16:32:34Z",
"nvd_published_at": "2026-04-30T21:16:32Z",
"severity": "HIGH"
},
"details": "## Summary\n\nThere is a high severity authentication bypass vulnerability in Traefik\u0027s `ForwardAuth` and snippet-based authentication middleware. Traefik\u0027s forwarded-header sanitization logic targets only canonical header names (e.g., `X-Forwarded-Proto`) and does not strip or normalize alias variants that use underscores instead of dashes (e.g., `X_Forwarded_Proto`). These unsanitized alias headers are forwarded intact to the authentication backend. When the backend normalizes underscore and dash header forms equivalently, an attacker can inject spoofed trust context \u2014 such as a trusted scheme or host \u2014 through the alias headers and bypass authentication on protected routes without valid credentials.\n\n## Patches\n\n- https://github.com/traefik/traefik/releases/tag/v2.11.43\n- https://github.com/traefik/traefik/releases/tag/v3.6.14\n- https://github.com/traefik/traefik/releases/tag/v3.7.0-rc.2\n\n## For more information\n\nIf there are any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues).\n\n\u003cdetails\u003e\n\u003csummary\u003eOriginal Description\u003c/summary\u003e\n\n### Summary\nAn authentication bypass arises from chaining two bugs: incomplete forwarded-header sanitization at ingress and overly permissive header forwarding in pre-auth subrequests. While canonical `X-Forwarded-*` headers are handled, alias variants (e.g., underscore forms) are neither normalized nor stripped consistently. When downstream auth services normalize these headers, attackers can inject trusted context and bypass authentication on protected routes without credentials.\n\n### Details\nThis issue results from the interaction between forwarded-header handling and auth subrequest construction, creating a trust boundary mismatch.\n\nAt ingress, Traefik defines a fixed set of canonical forwarded headers (`X-Forwarded-Proto`, `X-Forwarded-For`, etc.):\n\nReference : [`pkg/middlewares/forwardedheaders/forwarded_header.go#L29-L36`](https://github.com/traefik/traefik/blob/174e5d81111d8e9fb3d3c81cf6d22f3e33eb4f78/pkg/middlewares/forwardedheaders/forwarded_header.go#L29-L36)\n\n```go\nvar xHeaders = []string{\n\txForwardedProto,\n\txForwardedFor,\n\txForwardedHost,\n\txForwardedPort,\n```\n\nThis logic focuses exclusively on canonical header names and does not account for alias forms such as `X_Forwarded_Proto`. As a result, while standard headers may be sanitized or rewritten, semantically equivalent variants can pass through unchanged.\n\nDuring ForwardAuth processing, request headers are copied wholesale into the auth subrequest:\n\nReference : [`pkg/middlewares/auth/forward.go#L401-L408`](https://github.com/traefik/traefik/blob/174e5d81111d8e9fb3d3c81cf6d22f3e33eb4f78/pkg/middlewares/auth/forward.go#L401-L408)\n\n```go\nutils.CopyHeaders(forwardReq.Header, req.Header)\nRemoveConnectionHeaders(forwardReq)\nutils.RemoveHeaders(forwardReq.Header, hopHeaders...)\n```\n\nThis implementation forwards nearly all client-supplied headers to the auth backend, with filtering limited to hop-by-hop headers. There is no normalization or deduplication between canonical and alias header forms, meaning attacker-controlled headers can reach the auth service intact.\n\nA similar pattern exists in snippet-based auth:\n\nReference : [`pkg/middlewares/ingressnginx/snippet/snippet.go#L574-L581`](https://github.com/traefik/traefik/blob/174e5d81111d8e9fb3d3c81cf6d22f3e33eb4f78/pkg/middlewares/ingressnginx/snippet/snippet.go#L574-L581)\n\n```go\nutils.CopyHeaders(forwardReq.Header, req.Header)\nRemoveConnectionHeaders(forwardReq)\nutils.RemoveHeaders(forwardReq.Header, hopHeaders...)\n```\n\nAgain, headers are forwarded without enforcing a consistent trust model or canonicalization.\n\nThe vulnerability emerges when the auth backend normalizes header names (e.g., treating `X_Forwarded_Proto` and `X-Forwarded-Proto` equivalently). In that case:\n\n- Traefik sanitizes only canonical headers.\n- Alias headers remain attacker-controlled.\n- The auth service merges or evaluates these aliases during normalization.\n- Trust predicates (e.g., scheme = HTTPS, trusted host) are satisfied using spoofed values.\n\nThis allows a single crafted request to simultaneously bypass ingress trust enforcement and satisfy authentication checks, resulting in unauthorized access to protected backends.\n\n### PoC\n\n1. Configure a protected route using ForwardAuth or snippet-based auth, with an auth backend that normalizes header names (underscore \u2194 dash).\n2. Send a control request (expected: denied):\n\n```http\nGET / HTTP/1.1\nHost: target.local\nUser-Agent: poc-control\nConnection: close\n```\n\n3. Send an exploit request with alias headers (expected: allowed):\n\n```http\nGET /protected HTTP/1.1\nHost: app.example.local\nX_Forwarded_Proto: https\nX_Forwarded_Host: trusted.example\nConnection: close\n```\n\n### Impact\nThis vulnerability allows unauthenticated attackers to bypass authentication at the proxy-to-auth boundary by injecting spoofed trust context through header aliases. In deployments where authorization decisions depend on forwarded headers, attackers can access protected endpoints and interact with backend services as if they were fully authenticated. This effectively undermines ForwardAuth and similar mechanisms, potentially exposing sensitive internal functionality and data.\n\n### Suggested Remediation\n1. Strip and regenerate both canonical and alias forms of forwarded headers consistently at ingress and during auth subrequests.\n2. Apply a unified normalization policy across all forwarded header families (including RFC7239 and `X-Forwarded-*`).\n3. Restrict which headers are forwarded to auth services (prefer explicit allowlists).\n4. Add regression tests covering alias normalization inconsistencies across common backend frameworks.\n\n\u003c/details\u003e\n\n---",
"id": "GHSA-5m6w-wvh7-57vm",
"modified": "2026-05-06T21:24:39Z",
"published": "2026-04-24T16:32:34Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/security/advisories/GHSA-5m6w-wvh7-57vm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39858"
},
{
"type": "PACKAGE",
"url": "https://github.com/traefik/traefik"
},
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/releases/tag/v2.11.43"
},
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/releases/tag/v3.6.14"
},
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/releases/tag/v3.7.0-rc.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Traefik: Pre-authentication decision bypass due to forwarded alias spoofing"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.