V3: Traefik: Gateway HTTPRoute backendRef filters can leak backend context across routes sharing a Service:port (CVE-2026-54765)
## Summary There is a medium severity vulnerability in Traefik's Kubernetes Gateway API provider. When two accepted HTTPRoutes target the same backend Service:port but configure different `backendRef` filters, Traefik may resolve both routes to the same child service and apply only one route's filter set to all requests reaching that backend. In Gateway deployments where `backendRef` filters set security-sensitive headers — such as tenant identity, authorization context, or values the backend trusts — an attacker who can create an accepted HTTPRoute sharing the same backend Service:port may cause their route's filter context to be applied to another route's requests, potentially crossing namespace boundaries when a `ReferenceGrant` permits cross-namespace targeting. ## Patches - 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](https://github.com/traefik/traefik/issues). <details> <summary>Original Description</summary> # Traefik Gateway HTTPRoute backendRef filter context collision across routes sharing Service:port ## Summary Traefik's Kubernetes Gateway API provider builds the dynamic HTTP backend service key for a Gateway `HTTPRoute` backendRef from only the backend namespace, Service name, protocol, and port. It does not include the HTTPRoute, listener, rule, or backendRef filter identity in that key. When two accepted HTTPRoutes point to the same backend `Service:port` but define different backendRef filters, Traefik can make both route WRR services reference the same child service. The child service then carries only one backendRef filter set, so one route can send requests to the backend with another route's backend context. This is security-relevant when backendRef filters set, remove, or rewrite security-sensitive context, such as tenant, identity, auth, sanitization, Host, or path headers trusted by the backend. Credit: Qican Ma, Ding Luo @XiaoMi ShadowBlade Security Lab ## Suggested Severity Suggested severity: Medium/High, configuration-dependent. Suggested CVSS 3.1: ```text CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:H/A:N ``` Notes: - Requires Gateway API routes sharing the same backend Service:port with different security-sensitive backendRef filters trusted by the backend. - Cross-namespace impact is possible when route attachment and ReferenceGrant policy allow an attacker route to target the shared backend. - No RCE, memory corruption, or default-config exposure claimed. Suggested CWE: ```text CWE-863: Incorrect Authorization CWE-284: Improper Access Control ``` ## Affected Component ```text pkg/provider/kubernetes/gateway/httproute.go — loadService(), loadMiddlewares() ``` ## Tested Versions Confirmed on: ```text Traefik source snapshot: 29406d42898547f1ffabd904f66af06c212740cf on master ``` Earliest affected version not exhaustively determined. ## Root Cause `loadService` starts the dynamic service name from backend namespace and Service name only: ```go // pkg/provider/kubernetes/gateway/httproute.go:245 serviceName := provider.Normalize(namespace + "-" + string(backendRef.Name) + "-http") ``` It loads backendRef filters using that same service name before appending the backend port: ```go // pkg/provider/kubernetes/gateway/httproute.go:258 middlewares, err := p.loadMiddlewares(conf, namespace, serviceName, backendRef.Filters, pathMatch) ``` For normal Kubernetes Services, the final child service key appends only the port: ```go // pkg/provider/kubernetes/gateway/httproute.go:304-317 portStr := strconv.FormatInt(int64(port), 10) serviceName = provider.Normalize(serviceName + "-" + portStr) ... conf.HTTP.Services[serviceName] = &dynamic.Service{LoadBalancer: lb, Middlewares: middlewares} ``` Each route/rule WRR service references the child service by name. Later route configs are merged by map key (`maps.Copy`), so both route-local WRR services can point to the same child service, which retains only one of the route/backendRef filter configurations. ## Attack Scenario 1. Gateway listener with `allowedRoutes.namespaces.from: All`. 2. Victim `HTTPRoute` `route-a` in namespace `default` targets `default/whoami:80` with backendRef filter setting `X-Tenant: tenant-a`. 3. Attacker-controlled `HTTPRoute` `route-b` in namespace `attacker` targets `default/whoami:80` (via ReferenceGrant) with backendRef filter setting `X-Tenant: tenant-b`. 4. Both routes generate the same child service key: `default-whoami-http-80`. 5. The second route's filter configuration overwrites the first (or vice versa) via `maps.Copy`. 6. Backend receives both routes' requests with one tenant's header context. ## Proof of Concept A Go test harness injects provider-level and server-level tests into the Traefik checkout. The provider test confirms the generated dynamic configuration collision. The server test builds Traefik's runtime router/service/middleware pipeline and sends `h
AI Analysis
Technical Summary
Traefik's Kubernetes Gateway API provider constructs backend service keys using only the backend namespace, Service name, protocol, and port, omitting route-specific filter identities. When two HTTPRoutes target the same backend Service:port but specify different backendRef filters, Traefik may merge these routes to the same child service, which retains only one set of backendRef filters. This causes requests from one route to be processed with another route's backend context, including security-sensitive headers such as tenant identity or authorization context. This vulnerability is configuration-dependent and can lead to cross-namespace security context leakage when ReferenceGrant policies allow cross-namespace targeting. The vulnerability was confirmed on Traefik source snapshot 29406d42898547f1ffabd904f66af06c212740cf on master and affects versions >=3.7.0 <3.7.6. An official fix is available in version 3.7.6.
Potential Impact
An attacker who can create an accepted HTTPRoute sharing the same backend Service:port as a victim route may cause their backendRef filter context to be applied to the victim's requests. This can result in leakage of security-sensitive headers such as tenant identity or authorization context across routes, potentially crossing namespace boundaries if ReferenceGrant policies permit. There is no indication of remote code execution, memory corruption, or exposure of default configurations. The impact is primarily unauthorized access or incorrect authorization context being applied to backend requests.
Mitigation Recommendations
An official patch is available in Traefik version 3.7.6. Users should upgrade to this version or later to remediate the vulnerability. No additional mitigation steps are required if the patch is applied. Patch status is confirmed by the vendor advisory.
V3: Traefik: Gateway HTTPRoute backendRef filters can leak backend context across routes sharing a Service:port (CVE-2026-54765)
Description
## Summary There is a medium severity vulnerability in Traefik's Kubernetes Gateway API provider. When two accepted HTTPRoutes target the same backend Service:port but configure different `backendRef` filters, Traefik may resolve both routes to the same child service and apply only one route's filter set to all requests reaching that backend. In Gateway deployments where `backendRef` filters set security-sensitive headers — such as tenant identity, authorization context, or values the backend trusts — an attacker who can create an accepted HTTPRoute sharing the same backend Service:port may cause their route's filter context to be applied to another route's requests, potentially crossing namespace boundaries when a `ReferenceGrant` permits cross-namespace targeting. ## Patches - 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](https://github.com/traefik/traefik/issues). <details> <summary>Original Description</summary> # Traefik Gateway HTTPRoute backendRef filter context collision across routes sharing Service:port ## Summary Traefik's Kubernetes Gateway API provider builds the dynamic HTTP backend service key for a Gateway `HTTPRoute` backendRef from only the backend namespace, Service name, protocol, and port. It does not include the HTTPRoute, listener, rule, or backendRef filter identity in that key. When two accepted HTTPRoutes point to the same backend `Service:port` but define different backendRef filters, Traefik can make both route WRR services reference the same child service. The child service then carries only one backendRef filter set, so one route can send requests to the backend with another route's backend context. This is security-relevant when backendRef filters set, remove, or rewrite security-sensitive context, such as tenant, identity, auth, sanitization, Host, or path headers trusted by the backend. Credit: Qican Ma, Ding Luo @XiaoMi ShadowBlade Security Lab ## Suggested Severity Suggested severity: Medium/High, configuration-dependent. Suggested CVSS 3.1: ```text CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:H/A:N ``` Notes: - Requires Gateway API routes sharing the same backend Service:port with different security-sensitive backendRef filters trusted by the backend. - Cross-namespace impact is possible when route attachment and ReferenceGrant policy allow an attacker route to target the shared backend. - No RCE, memory corruption, or default-config exposure claimed. Suggested CWE: ```text CWE-863: Incorrect Authorization CWE-284: Improper Access Control ``` ## Affected Component ```text pkg/provider/kubernetes/gateway/httproute.go — loadService(), loadMiddlewares() ``` ## Tested Versions Confirmed on: ```text Traefik source snapshot: 29406d42898547f1ffabd904f66af06c212740cf on master ``` Earliest affected version not exhaustively determined. ## Root Cause `loadService` starts the dynamic service name from backend namespace and Service name only: ```go // pkg/provider/kubernetes/gateway/httproute.go:245 serviceName := provider.Normalize(namespace + "-" + string(backendRef.Name) + "-http") ``` It loads backendRef filters using that same service name before appending the backend port: ```go // pkg/provider/kubernetes/gateway/httproute.go:258 middlewares, err := p.loadMiddlewares(conf, namespace, serviceName, backendRef.Filters, pathMatch) ``` For normal Kubernetes Services, the final child service key appends only the port: ```go // pkg/provider/kubernetes/gateway/httproute.go:304-317 portStr := strconv.FormatInt(int64(port), 10) serviceName = provider.Normalize(serviceName + "-" + portStr) ... conf.HTTP.Services[serviceName] = &dynamic.Service{LoadBalancer: lb, Middlewares: middlewares} ``` Each route/rule WRR service references the child service by name. Later route configs are merged by map key (`maps.Copy`), so both route-local WRR services can point to the same child service, which retains only one of the route/backendRef filter configurations. ## Attack Scenario 1. Gateway listener with `allowedRoutes.namespaces.from: All`. 2. Victim `HTTPRoute` `route-a` in namespace `default` targets `default/whoami:80` with backendRef filter setting `X-Tenant: tenant-a`. 3. Attacker-controlled `HTTPRoute` `route-b` in namespace `attacker` targets `default/whoami:80` (via ReferenceGrant) with backendRef filter setting `X-Tenant: tenant-b`. 4. Both routes generate the same child service key: `default-whoami-http-80`. 5. The second route's filter configuration overwrites the first (or vice versa) via `maps.Copy`. 6. Backend receives both routes' requests with one tenant's header context. ## Proof of Concept A Go test harness injects provider-level and server-level tests into the Traefik checkout. The provider test confirms the generated dynamic configuration collision. The server test builds Traefik's runtime router/service/middleware pipeline and sends `h
CVSS v4.0
Affected software
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
Traefik's Kubernetes Gateway API provider constructs backend service keys using only the backend namespace, Service name, protocol, and port, omitting route-specific filter identities. When two HTTPRoutes target the same backend Service:port but specify different backendRef filters, Traefik may merge these routes to the same child service, which retains only one set of backendRef filters. This causes requests from one route to be processed with another route's backend context, including security-sensitive headers such as tenant identity or authorization context. This vulnerability is configuration-dependent and can lead to cross-namespace security context leakage when ReferenceGrant policies allow cross-namespace targeting. The vulnerability was confirmed on Traefik source snapshot 29406d42898547f1ffabd904f66af06c212740cf on master and affects versions >=3.7.0 <3.7.6. An official fix is available in version 3.7.6.
Potential Impact
An attacker who can create an accepted HTTPRoute sharing the same backend Service:port as a victim route may cause their backendRef filter context to be applied to the victim's requests. This can result in leakage of security-sensitive headers such as tenant identity or authorization context across routes, potentially crossing namespace boundaries if ReferenceGrant policies permit. There is no indication of remote code execution, memory corruption, or exposure of default configurations. The impact is primarily unauthorized access or incorrect authorization context being applied to backend requests.
Mitigation Recommendations
An official patch is available in Traefik version 3.7.6. Users should upgrade to this version or later to remediate the vulnerability. No additional mitigation steps are required if the patch is applied. Patch status is confirmed by the vendor advisory.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-6p8f-p8j2-rqmv
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-54765"]
- Ecosystems
- ["Go"]
- Database Specific Severity
- MODERATE
- Cvss Version
- 4.0
Threat ID: 6a74cf62bf8831d53918f6f3
Added to database: 08/06/2026, 18:16:02 UTC
Last enriched: 08/06/2026, 18:19:07 UTC
Last updated: 08/07/2026, 00:41:15 UTC
Views: 3
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.