Improper authorization control for web services In github.com/traefik/traefik
Description
Traefik: Kubernetes Gateway crossProviderNamespaces bypass allows HTTPRoute outside the allowlist to expose internal Traefik services ## Summary There 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. ## Patches - https://github.com/traefik/traefik/releases/tag/v3.6.21 - https://github.com/traefik/traefik/releases/tag/v3.7.5 ## For more information If you have any questions or comments about this advisory, please open an issue.
Original Description
# Summary The Kubernetes Gateway provider'scrossProviderNamespaces 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 Behavior With: yaml providers: kubernetesGateway: crossProviderNamespaces: - trusted 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: yaml backendRefs: - group: traefik.io kind: TraefikService name: api@internal namespace: trusted # Actual Behavior For an HTTPRoute in namespace attacker with two backendRefs, Traefik generates a WRR service containing: text [api@internal attacker-whoami-http-80] even though crossProviderNamespaces only allows trusted. # Threat Model This 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 Capability Required: - 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 Evidence The 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: text List of namespaces from which Gateway API routes (HTTPRoute, TCPRoute, TLSRoute) are allowed to declare a backendRef of kind TraefikService. The migration notes also describe the security reason for the option: text those references ... allow a user to cross namespace boundaries, as well as exposing @internal services, that only the operator should be able to expose. and the documented behavior is: text ["ns-a"] | Only Kubernetes resources in the listed namespaces can declare cross-provider references. The provider struct uses the same route-namespace wording: go CrossProviderNamespaces []string `description:"List of namespaces from which Gateway API routes are allowed to declare TraefikService backendRef references." ...` The reproduced route kind is HTTPRoute; no Gateway API experimental-channel resources are required for the PoC. # PoC I 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: text external-repro-kind/kind-config.yaml external-repro-kind/traefik-v371.yaml external-repro-kind/gateway-exploit.yaml external-repro-kind/run-kind-repro.sh Run command: bash ./external-repro-kind/run-kind-repro.sh 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: text --api=true --api.dashboard=true --api.insecure=false --providers.kubernetesgateway=true --providers.kubernetesgateway.crossprovidernamespaces=trusted The local host entrypoint was: text 127.0.0.1:18080 -> kind NodePort -> Traefik web entrypoint The target namespace has a normal Gateway API ReferenceGrant: yaml apiVersion: gateway.networking.k8s.io/v1beta1 kind: ReferenceGrant metadata: name: allow-attacker-to-traefikservice namespace: trusted spec: from: - group: gateway.networking.k8s.io kind: HTTPRoute namespace: attacker to: - group: traefik.io kind: TraefikService Positive control: yaml apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: single-backend-control namespace: attacker spec: parentRefs: - name: shared-gateway namespace: default hostnames: - control.localhost rules: - matches: - path: type: PathPrefix value: /api backendRefs: - group: traefik.io kind: TraefikService name: api@internal namespace: trusted port: 80 weight: 1 Bypass: yaml apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: mixed-backend-bypass namespace: attacker spec: parentRefs: - name: shared-gateway namespace: default hostnames: - exploit.localhost rules: - matches: - path: type: PathPrefix value: /api backendRefs: - group: traefik.io kind: TraefikService name: api@internal namespace: trusted port: 80 weight: 1000000 - group: "" kind: Service name: whoami port: 80 weight: 1 Observed external result:Mitigation
Update Impact
Minimal update. May introduce new vulnerabilities or breaking changes.
Ecosystem | Component | Affected version | Patched versions |
|---|---|---|---|
 go | 2.0.0-alpha1+incompatible | ||
go | 3.6.21, 3.7.5 | ||
go | 2.11.51 |
Aliases
1. 2. 3. 4. 5.
References
1. 2. 3. 4.