Summary

When providers.kubernetesCRD.allowCrossNamespace=false (the default), Traefik correctly rejects cross-namespace @kubernetescrd references for middlewares, TLS options, and HTTP/TCP ServersTransport, but it does not apply the same restriction to service (TraefikService) backendRefs. As a result, a Kubernetes tenant who is confined by RBAC to their own namespace can bind their own router to a TraefikService owned by another namespace simply by referencing it as <victim-namespace>-<name>@kubernetescrd, defeating the namespace-isolation boundary that allowCrossNamespace=false is meant to enforce.

This is the service-resolver sibling of the cross-namespace isolation family that Traefik has been fixing one resolver at a time (df00d82f / CVE-2026-41174 for Chain middlewares, and 67501cbe for TCP ServersTransport, which shipped in v3.7.7 only four days before the analyzed commit). The TraefikService resolver in configBuilder.nameAndService was never given the guard its sibling resolvers received.

Details

Root cause

nameAndService only performs the same-namespace check (isNamespaceAllowed) inside the branch that handles names without an @ separator. For names that contain an @ separator (that is, @kubernetescrd cross-namespace references) it applies only the crossProviderNamespaces allowlist check, and that check returns true by default because a nil allowlist means "unrestricted". It never applies the !allowCrossNamespace && strings.HasSuffix(name, "@kubernetescrd") rejection that the sibling resolvers all apply, so allowCrossNamespace=false is effectively never consulted for @kubernetescrd service references.

Vulnerable code

// pkg/provider/kubernetes/crd/kubernetes_http.go:662-695 — nameAndService (VULNERABLE)
func (c configBuilder) nameAndService(ctx context.Context, parentNamespace string, service traefikv1alpha1.LoadBalancerSpec) (string, *dynamic.Service, error) {
	svcCtx := log.Ctx(ctx).With().Str(logs.ServiceName, service.Name).Logger().WithContext(ctx)

	if !strings.Contains(service.Name, providerNamespaceSeparator) { // 665: only names WITHOUT "@"
		service = *service.DeepCopy()
		service.Namespace = namespaceOrParentNamespace(service.Namespace, parentNamespace)
		if !isNamespaceAllowed(c.allowCrossNamespace, parentNamespace, service.Namespace) { // 669
			return "", nil, fmt.Errorf("service %s/%s not in the parent resource namespace %s", ...)
		}
	}

	// 674: for "@"-names, the ONLY gate is crossProviderNamespaces, which defaults to allow-all (nil).
	if !isCrossProviderNamespaceAllowed(c.crossProviderNamespaces, parentNamespace) && strings.Contains(service.Name, providerNamespaceSeparator) {
		return "", nil, fmt.Errorf("service %q reference is not allowed: ...", service.Name)
	}
	// ^-- MISSING: no `!c.allowCrossNamespace && strings.HasSuffix(service.Name, "@"+ProviderName)` rejection.

	switch service.Kind {
	case "TraefikService":
		return fullServiceName(svcCtx, service, intstr.FromInt(0)), nil, nil // 690: returns the cross-namespace reference
	...
	}
}

For comparison, the sibling resolver used for middleware and TLS references does carry the guard:

// pkg/provider/kubernetes/crd/kubernetes.go:1653-1668 — resolveReference (CORRECT)
func resolveReference(ctx context.Context, parentNs, ns, name string, crossProviderNamespaces []string, allowCrossNamespace bool) (string, error) {
	if strings.Contains(name, providerNamespaceSeparator) {
		if !allowCrossNamespace && strings.HasSuffix(name, providerNamespaceSeparator+ProviderName) {
			return "", errors.New("when allowCrossNamespace is disabled, @kubernetescrd references are disallowed") // 1656 — THE GUARD
		}
		...
	}
	...
}

The same guard is also present at pkg/provider/kubernetes/crd/kubernetes_http.go:500 (makeServersTransportKey, HTTP) and pkg/provider/kubernetes/crd/kubernetes_tcp.go:316 (makeTCPServersTransportKey, TCP, added by commit 67501cbe). Only the service resolver nameAndService lacks it.

Data flow

An IngressRoute created by a tenant in namespace attacker declares a route service { name: "victim-backend@kubernetescrd", kind: TraefikService }; the tenant controls this reference string. In nameAndService, because the name contains @, the same-namespace check at line 669 is skipped, and isCrossProviderNamespaceAllowed(nil, "attacker") returns true under the default nil allowlist, so no rejection fires. fullServiceName then resolves the reference to the victim namespace's TraefikService, and the attacker's HTTP router is generated and bound to the victim's backend. At runtime the attacker's Host(...) route forwards to namespace victim's backend pods.

Default reachability

AllowCrossNamespace defaults to false (pkg/provider/kubernetes/crd/kubernetes.go:57, never set to true by any SetDefaults), so the isolation this bug bypasses is on by default. CrossProviderNamespaces defaults to nil, and isCrossProviderNamespaceAllowed returns true for a nil allowlist (pkg/provider/kubernetes/crd/kubernetes.go:1645-1651), so the only check nameAndService applies to an @-name is inert by default. The attacker needs only namespace-scoped RBAC to create an IngressRoute or TraefikService in their own namespace (the standard hard-multi-tenant Traefik setup) and knowledge of the target TraefikService's namespace and name.

PoC

A table-style harness was added to the CRD provider package. It defines a victim TraefikService (backend in namespace victim, backed by a real endpoint) and an attacker IngressRoute (namespace attacker) that references it via victim-backend@kubernetescrd, plus a control route that references a victim Middleware via victim-mw@kubernetescrd. The control route is given a valid local service so that the only reason it could be dropped is the cross-namespace middleware guard. The provider is run with AllowCrossNamespace: false and CrossProviderNamespaces: nil (both defaults).

$ go test -run TestPoC_CrossNamespaceServiceBypass ./pkg/provider/kubernetes/crd/ -v

HTTP routers:  [attacker-attacker-svc-route-7df4381938699bd21215]
HTTP services: [victim-whoami-victim-80 victim-backend]
CONTROL OK: cross-ns MIDDLEWARE ref (victim-mw@kubernetescrd) rejected -> router dropped
BYPASS CONFIRMED: attacker router bound to cross-ns service "victim-backend" despite AllowCrossNamespace=false

The control route (middleware reference) is dropped even though it has a valid local service, confirming that the isolation control is active for middlewares; the service route survives and its Service field resolves to victim-backend, with the victim's services pulled into the generated configuration and reachable through the attacker's router.

The harness also runs two corroborating cases. With AllowCrossNamespace=false and CrossProviderNamespaces=["someotherns"] (an allowlist that excludes the attacker), the service reference is blocked, which proves that the only gate ever applied to an @kubernetescrd service name is crossProviderNamespaces (inert by default) and that allowCrossNamespace=false is never consulted. With AllowCrossNamespace=true, both the service and middleware references are accepted, as expected when isolation is intentionally disabled.

Impact

In a multi-tenant cluster relying on allowCrossNamespace=false for namespace isolation, a tenant confined to their own namespace can attach their own router (their own Host rule and entrypoint) to another tenant's TraefikService backend, exposing an otherwise internal-only service on the data plane under the attacker's hostname, and can route or mirror traffic to another namespace's backend that they should not be able to reference.