| Package | Affected versions | Patched versions |
|---|---|---|
| github.com/traefik/traefik | ≤ 1.7.34all versions | |
| github.com/traefik/traefik/v2 | < 2.11.46 | 2.11.46 |
| github.com/traefik/traefik/v3 | ≥ 3.7.0, < 3.7.1< 3.6.17 | 3.7.13.6.17 |
| traefik | ≥ 3.0.0, < 3.6.17≥ 3.7.0, < 3.7.1< 2.11.46 | 3.6.173.7.12.11.46 |
There is a medium severity vulnerability in Traefik's Kubernetes Gateway API provider that allows a tenant with HTTPRoute creation permissions to expose the REST provider handler, bypassing the providers.rest.insecure=false setting. The Gateway provider accepts any TraefikService backend reference whose name ends with @internal, making it possible to route traffic to rest@internal in addition to the intended api@internal. In shared Gateway deployments where the REST provider is enabled, this allows a low-privileged actor to gain live dynamic configuration write access to Traefik, enabling unauthorized reconfiguration of routers and services.
If you have any questions or comments about this advisory, please open an issue.
<details> <summary>Original Description</summary>When the Kubernetes Gateway API provider is enabled, Traefik accepts any TraefikService backend whose name ends with @internal. This allows a tenant-controlled HTTPRoute to publish rest@internal.
If providers.rest is enabled, this exposes Traefik's REST provider handler even when providers.rest.insecure=false, even though providers.rest.insecure=false is meant to keep the REST handler from being exposed by Traefik's built-in internal router. In a shared Gateway deployment, an actor with permission to create or update HTTPRoute resources in an allowed namespace can gain live Traefik dynamic-configuration write access through PUT /api/providers/rest.
The Gateway provider treats internal services broadly rather than allowing only a specific internal target.
In current master, pkg/provider/kubernetes/gateway/kubernetes.go defines isInternalService(...) as any TraefikService reference whose name ends with @internal.
Then pkg/provider/kubernetes/gateway/httproute.go special-cases a single backend reference that matches isInternalService(...) and directly assigns router.Service = string(routeRule.BackendRefs[0].Name).
This means a tenant route can target not only api@internal, but also rest@internal and other internal handlers.
Separately, the REST provider handler is created whenever the REST provider is enabled. In pkg/server/service/managerfactory.go, if staticConfiguration.Providers.Rest != nil, Traefik sets factory.restHandler = staticConfiguration.Providers.Rest.CreateRouter().
The REST provider handler itself is implemented in pkg/provider/rest/rest.go and accepts PUT /api/providers/{provider}.
The providers.rest.insecure flag does not disable the underlying handler. In pkg/provider/traefik/internal.go, that flag only controls whether Traefik creates its own built-in internal router for rest@internal. Even when providers.rest.insecure=false, Traefik still registers the rest service object, and the service layer can still resolve rest@internal if another provider routes to it.
I validated this locally in two tests:
rest@internal as an internal backend through the same special-case branch used for api@internalrest@internal successfully when providers.rest is enabled and providers.rest.insecure=falseThe vulnerable code path is present in:
v3.0.0v3.6.7v2.11.0v2.11.36master at 786f7192e11878dfaa634f8263bf79bb730a71cbI verified the issue in v3.0.0, v3.6.7, v2.11.0, v2.11.36, and current master; the reported affected ranges reflect the maintained release lines checked during validation
I did not find a public Traefik advisory or CVE for this exact issue. The closest public overlap I found is the documented/tested Gateway support for api@internal, but the issue here is broader because the Gateway code accepts any @internal TraefikService, including the write-capable rest@internal handler.
providers.rest.insecure=false should prevent low-privileged route authors from exposing the REST provider handler.
A tenant-controlled Gateway route can still publish rest@internal and reach the REST update API.
providers.rest=true.providers.rest.insecure=false.HTTPRoute resources.HTTPRoute resources in an allowed tenant namespace.Example static configuration:
providers:
kubernetesGateway: {}
rest:
insecure: false
Ensure a shared Gateway allows tenant HTTPRoute attachment.
In an allowed tenant namespace, create an HTTPRoute whose backend points to rest@internal:
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: expose-rest-internal
namespace: tenant-a
spec:
parentRefs:
- name: shared-gateway
namespace: infra
hostnames:
- rest.tenant.example
rules:
- matches:
- path:
type: PathPrefix
value: /
backendRefs:
- group: traefik.io
kind: TraefikService
name: rest@internal
port: 80
PUT request through that published route to /api/providers/rest with a valid dynamic configuration body. A harmless proof can add a dummy router pointing to noop@internal.Example request body:
{
"http": {
"routers": {
"probe": {
"rule": "PathPrefix(`/probe`)",
"service": "noop@internal",
"ruleSyntax": "default"
}
}
}
}
providers.rest.insecure=false.This is an authorization / trust-boundary bypass affecting shared Gateway deployments.
On affected deployments, an actor who should only be able to create or update HTTPRoute objects can escalate to live Traefik dynamic-configuration write access. That can allow unauthorized reconfiguration of routers and services, publication of additional internal surfaces, request interception or rerouting, and denial of service through destructive config changes.
On affected deployments, this gives a low-privileged Gateway route author live Traefik dynamic-configuration write access. This is critical for affected shared Gateway deployments because it can give a low-privileged route author live Traefik dynamic-configuration write access, but it depends on providers.rest being enabled.
This is not an unauthenticated vulnerability in all Traefik deployments. The issue depends on realistic but specific conditions:
providers.rest must be enabledHTTPRoute resources to a shared GatewayRunning one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site free