GHSA-6p8f-p8j2-rqmv Traefik: Gateway HTTPRoute backendRef filters can leak backend context across routes sharing a Service:port
SummaryThere 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.Patcheshttps://github.com/traefik/traefik/releases/tag/v3.7.6For more informationIf you have any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues).Traefik Gateway HTTPRoute backendRef filter context collision across routes sharing Service:portSummaryTraefik'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 LabSuggested SeveritySuggested severity: Medium/High, configuration-dependent.Suggested CVSS 3.1: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:Affected ComponentTested VersionsConfirmed on:Earliest affected version not exhaustively determined.Root Cause`loadService` starts the dynamic service name from backend namespace and Service name only:It loads backendRef filters using that same service name before appending the backend port:For normal Kubernetes Services, the final child service key appends only the port: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 ScenarioGateway listener with `allowedRoutes.namespaces.from: All`.Victim `HTTPRoute` `route-a` in namespace `default` targets `default/whoami:80` with backendRef filter setting `X-Tenant: tenant-a`.Attacker-controlled `HTTPRoute` `route-b` in namespace `attacker` targets `default/whoami:80` (via ReferenceGrant) with backendRef filter setting `X-Tenant: tenant-b`.Both routes generate the same child service key: `default-whoami-http-80`.The second route's filter configuration overwrites the first (or vice versa) via `maps.Copy`.Backend receives both routes' requests with one tenant's header context.Proof of ConceptA 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 `httptest` requests through router matching, WRR service dispatch, service-level backendRef middleware, and backend proxy capture.Observed result:Negative controls confirmed:Separate backend Service:port keys produce correct per-route filter isolation.Identical filters across routes produce no security-relevant difference.The PoC files can be shared upon request.ImpactAn actor who can create or modify an accepted HTTPRoute can cause another accepted route that targets the same backend Service:port to use the wrong backendRef filter context. In cross-namespace Gateway deployments, this can cross namespace boundaries.High-value impact: gateway-injected tenant, identity, auth, role, header sanitization, Host rewrite, or path rewrite context is trusted by the backend.
Lower-value impact: the overwritten header is informational or observability-only.Suggested RemediationInclude route/listener/rule/backendRef filter identity in the generated child service name when backendRef filters are present.Split the load-balancer service from the backendRef filter application so per-route backend filters remain route-scoped.Detect conflicting backendRef filters for the same generated service key and reject or disambiguate the configuration.Timeline
CVSS v4.0 score: 6.3