GHSA-3g6v-2r68-prfc Traefik: Kubernetes Gateway crossProviderNamespaces bypass allows HTTPRoute outside the allowlist to expose internal Traefik services
SummaryThere is a high severity vulnerability in Traefik's Kubernetes Gateway provider affecting the `crossProviderNamespaces` allowlist. For `HTTPRoute` rules that declare multiple (WRR) backendRefs, Traefik evaluates the allowlist against the target `backendRef.namespace` instead of the route's own namespace. As a result, an `HTTPRoute` created in a namespace that is not allow-listed can reference a cross-provider `TraefikService` such as `api@internal`, `dashboard@internal` or `rest@internal` by pointing `backendRef.namespace` at an allow-listed namespace covered by a Gateway API `ReferenceGrant`, exposing internal Traefik services on the data plane. Exploitation requires the ability to create an accepted `HTTPRoute` and a matching `ReferenceGrant` from an allow-listed namespace ; it does not require any change to Traefik static configuration, RBAC, or the deployment itself.Patcheshttps://github.com/traefik/traefik/releases/tag/v3.6.21https://github.com/traefik/traefik/releases/tag/v3.7.5For more informationIf you have any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues).SummaryThe Kubernetes Gateway provider's `crossProviderNamespaces` option is documented as restricting which Gateway API route namespaces may declare `TraefikService` backendRefs.For `HTTPRoute` rules with multiple backendRefs, Traefik checks this allowlist against `backendRef.namespace` instead of the `HTTPRoute` namespace. A route in a namespace that is not allow-listed can therefore add `api@internal` to the generated WRR service by setting `backendRef.namespace` to an allow-listed namespace, as long as a normal Gateway API `ReferenceGrant` permits that cross-namespace reference.Verified affected versions:`v3.7.1` (`fa49e2bcad7ffd8a80accdf1fae1ae480913d93d`)current source/master tested by me (`29406d42898547f1ffabd904f66af06c212740cf`)Expected BehaviorWith:only Gateway API routes whose own namespace is `trusted` should be allowed to declare `TraefikService` backendRefs such as `api@internal`, `dashboard@internal`, or `rest@internal`.An `HTTPRoute` in namespace `attacker` should not be able to expose an internal Traefik service by setting:Actual BehaviorFor an `HTTPRoute` in namespace `attacker` with two backendRefs, Traefik generates a WRR service containing:even though `crossProviderNamespaces` only allows `trusted`.Threat ModelThis does not require changing Traefik static configuration or Traefik process state. The relevant boundary is the Kubernetes Gateway provider's `crossProviderNamespaces` policy: namespaces outside the allowlist should not be able to declare cross-provider `TraefikService` backendRefs.The precondition is a Gateway API environment where an untrusted or less-trusted namespace can create `HTTPRoute` objects accepted by a Gateway, and a namespace in the `crossProviderNamespaces` allowlist has a matching `ReferenceGrant`. `ReferenceGrant` should satisfy Gateway API cross-namespace reference rules, but it should not override Traefik's separate provider-level namespace allowlist for cross-provider internal services.A Gateway API `ReferenceGrant` should be treated as necessary but not sufficient for this case. It authorizes the cross-namespace object reference under Gateway API rules, but Traefik's `crossProviderNamespaces` option is an additional Traefik-specific security control for cross-provider `TraefikService` backendRefs, especially `@internal` services. Therefore a `ReferenceGrant` from `trusted` must not make a route in `attacker` equivalent to a route whose own namespace is `trusted`.Required Attacker CapabilityRequired:create or modify an `HTTPRoute` in namespace `attacker`;have that `HTTPRoute` accepted by a `Gateway`;rely on an existing `ReferenceGrant` from an allow-listed namespace, or on a delegated namespace setup where such `ReferenceGrant` objects are managed separately from Traefik's provider configuration.Not required:modifying Traefik static configuration;modifying the Traefik deployment or Traefik RBAC;modifying resources in the Traefik deployment namespace;modifying `providers.kubernetesGateway.crossProviderNamespaces`;enabling `api.insecure`;exposing the dashboard/API entrypoint directly.Documentation EvidenceThe documented boundary is the namespace of the Gateway API route/resource that declares the cross-provider reference, not the namespace named in `backendRef.namespace`.The Kubernetes Gateway provider option is documented as:The migration notes also describe the security reason for the option:and the documented behavior is:The provider struct uses the same route-namespace wording:The reproduced route kind is `HTTPRoute`; no Gateway API experimental-channel resources are required for the PoC.PoCI validated the issue end-to-end in a local `kind` cluster with Traefik `v3.7.1`, real Gateway API CRDs, real Kubernetes `Gateway`, `HTTPRoute`, and `ReferenceGrant` resources, and HTTP requests to Traefik's normal `web` entrypoint.The complete local reproducer I used is a self-contained `kind` PoC with these files:Run command:The script creates a local `kind` cluster, loads local `traefik:v3.7.1` and `traefik/whoami:v1.11.0` images, installs Gateway API CRDs, deploys Traefik and the PoC Gateway resources, sends the control and exploit `curl` requests to `127.0.0.1:18080`, prints route status, and deletes the cluster on exit.Traefik was started with:The local host entrypoint was:The target namespace has a normal Gateway API `ReferenceGrant`:Positive control:Bypass:Observed external result:The `HTTPRoute` status shows the boundary difference:This is the externally visible security failure: the same route namespace and same `api@internal` backendRef are rejected in the single-backend path, but accepted in the mixed/WRR path and exposed on the data plane.Minimized Root Cause TestI also created a provider-level regression test using Traefik's fake Kubernetes/Gateway clients. This does not rely on the Docker lab, dashboard exposure, or helper backends. It is useful as a minimal root-cause test, but the external `kind` PoC above is the primary impact reproduction.Files:`probe/crossprovider_namespace_probe_test.go``probe/cross_provider_namespace_probe.yml``probe/cross_provider_namespace_single_control.yml`Reproduction:Observed output on both tested versions:The reproducer also includes a positive control:That control shows the single-backend internal-service code path rejects the setup correctly. The bypass appears when the same forbidden internal backend is placed in a mixed/WRR backendRef list.Root CauseThe single-internal-service path checks the route namespace:The mixed/multiple backendRef path calls `loadService`. In `loadService`, `namespace` is overwritten from `backendRef.Namespace`, then passed to `loadHTTPBackendRef`:`loadHTTPBackendRef` then checks `crossProviderNamespaces` against this target namespace:This lets a disallowed route namespace choose an allow-listed target namespace and pass the check.ImpactAn untrusted route namespace may expose internal Traefik services through Gateway `HTTPRoute` despite being excluded from `crossProviderNamespaces`.Potentially exposed internal services include:`api@internal``dashboard@internal``rest@internal`This is a route isolation / internal service exposure / security option bypass. Practical severity depends on whether internal services are enabled and how Gateway `ReferenceGrant` delegation is used, but the observed behavior violates the documented security boundary of `crossProviderNamespaces`.I also validated the concrete impact of the generated service graph in the local lab. The lab's intended safe baseline has the dashboard/API protected on the dashboard entrypoint:When a router on the normal web entrypoint references `api@internal`, the same API endpoint becomes unauthenticated:A WRR service containing `api@internal` also exposes the API:This is the security consequence of the provider bug: a namespace that should be blocked by `crossProviderNamespaces` can make Traefik generate a service graph containing `api@internal` on a route it controls.Suggested FixFor Gateway `HTTPRoute` `TraefikService` cross-provider backendRefs, validate `crossProviderNamespaces` against `route.Namespace` in all code paths, including mixed/WRR backendRefs.
CVSS v4.0 score: 6
CVSS v3.1 score: 7.1