CVE-2026-65602: IngressRouteTCP ServersTransport Namespace Bypass in Traefik

Traefik is a modern HTTP reverse proxy and load balancer designed to integrate with cluster orchestrators like Kubernetes. In multi-tenant environments, security isolation between different namespaces is critical to ensure that tenants cannot interfere with or access administrative configurations. To enforce this boundary, Traefik implements a security configuration known as 'crossProviderNamespaces'. This setting acts as an access control list, defining which Kubernetes namespaces are allowed to reference resources across provider boundaries.

Historically, the 'crossProviderNamespaces' configuration array was correctly evaluated when processing standard IngressRoute HTTP configurations. This prevented unauthorized namespaces from accessing file-based resources, which often contain highly sensitive parameters such as mTLS client certificates, SPIFFE workload identities, or custom proxy-protocol setups. By maintaining strict provider-namespace isolation, administrators could ensure that low-privileged users in localized tenant namespaces could not use cluster-wide privileged configuration definitions.

However, a verification gap was introduced in the parsing path of the IngressRouteTCP configuration parser. Specifically, the parser failed to evaluate the namespace allowlist constraints when evaluating serversTransport bindings. As a result, any user capable of creating an IngressRouteTCP resource could bypass the intended namespace barriers to reference privileged, administrative-level transports. This logical flaw effectively allowed any low-privileged Kubernetes tenant to exploit sensitive backend transport layers, undermining the core multi-tenant security architecture of the host cluster.

The root cause of this vulnerability lies within the configuration compilation engine of Traefik's Kubernetes Custom Resource Definition (CRD) provider. When configuring network ingress, Traefik allows routers to bind to specific 'serversTransport' resources, which define the underlying TLS settings, socket options, and proxy behaviors for backend communication. These transports are defined across various providers, with the static file provider ('@file') typically reserved for cluster-wide, highly privileged transport definitions.

In the Kubernetes CRD provider codebase, specifically within the function 'makeTCPServersTransportKey' in 'pkg/provider/kubernetes/crd/kubernetes_tcp.go', the code parses references to administrative server transports. When a reference containing a provider separator (the '@' symbol) is parsed, the code must check whether the originating namespace is authorized to access the destination provider. While the HTTP parsing pipeline enforced this restriction using the 'isCrossProviderNamespaceAllowed' validator, the TCP configuration pipeline omitted this verification step.

Specifically, the vulnerable implementation of 'makeTCPServersTransportKey' checked for the presence of the provider namespace separator using a basic string evaluation. If the separator was detected, the method immediately returned the transport reference key, executing a fast return path without performing any validation against the 'crossProviderNamespaces' configuration. This programming oversight bypassed the authorized namespace collection completely, letting any IngressRouteTCP manifest bind to external provider configurations.

Analyzing the patch applied in commit 67501cbe7bc7774e26ecbd1c29af97f098e14b0b clarifies the exact missing validation step and the fix implementation. In the vulnerable release of pkg/provider/kubernetes/crd/kubernetes_tcp.go, the processing logic returned early upon encountering a provider separator.

// Vulnerable Code Logic
if strings.Contains(serversTransportName, providerNamespaceSeparator) {
	return serversTransportName, nil
}

This early return completely bypassed the namespace containment check. The patch corrected this behavior by embedding the proper verification check directly into the provider-separated evaluation block. By invoking the authorization checker helper function, the TCP configuration engine now validates the originating namespace against the active allowlist.

// Patched Code Logic
if strings.Contains(serversTransportName, providerNamespaceSeparator) {
	if !p.AllowCrossNamespace && strings.HasSuffix(serversTransportName, providerNamespaceSeparator+providerName) {
		return "", fmt.Errorf("invalid reference to serversTransport %s: namespace-name@kubernetescrd format is not allowed when crossnamespace is disallowed", serversTransportName)
	}
 
	if !isCrossProviderNamespaceAllowed(p.CrossProviderNamespaces, parentNamespace) {
		return "", fmt.Errorf("serversTransport %q reference is not allowed: namespace %q is not in crossProviderNamespaces", serversTransportName, parentNamespace)
	}
 
	return serversTransportName, nil
}

With this update, if an unauthorized namespace attempts to leverage a transport containing the @file suffix, the validation fails. The parsing sequence aborts, throwing an error and refusing to reconcile the unauthorized route. This ensures complete parity between the HTTP and TCP configurations and effectively closes the authorization bypass.

Exploitation of CVE-2026-65602 requires low-privileged administrative access inside a restricted namespace in a multi-tenant Kubernetes cluster. The attacker must target a cluster where a privileged, global transport is configured in a static file provider, such as an mTLS connection profile used for secure database or API gateway tunnels. The attacker does not need any administrative permissions outside of their local, designated namespace.

To execute the exploit, the malicious tenant crafts an IngressRouteTCP manifest that references the target file-provider transport. By applying this configuration to their namespace, they instruct the Traefik proxy controller to bind their custom backend service to the administrative-grade TCP transport. The key component of the exploit is the use of the @file provider suffix in the serversTransport key.

apiVersion: traefik.io/v1alpha1
kind: IngressRouteTCP
metadata:
  name: bypass-route
  namespace: untrusted-tenant-namespace
spec:
  entryPoints:
    - websecure
  routes:
    - match: HostSNI(`exploit.internal.corp`)
      services:
        - name: internal-attacker-service
          port: 443
          serversTransport: admin-mtls-transport@file

Once the controller reconciles this resource, the attacker can establish a TLS session targeting exploit.internal.corp. Traefik then routes the traffic to the specified internal backend service while using the sensitive client identity, proxy protocol flags, or backend certificates configured in admin-mtls-transport@file. This enables unauthorized operations, such as authenticating to downstream resources using administrative certificates.

The security impact of this vulnerability is characterized as an incorrect authorization check (CWE-863) resulting in privilege escalation (T1068). Although scored at 5.3 (Medium) under CVSS v4.0, the subsequent system confidentiality and integrity impacts are high. In modern enterprise environments, serversTransports are the standard mechanism for housing mutual TLS (mTLS) identities, making them critical security boundaries.

An attacker who successfully exploits this bypass can reuse backend connections established under a different security profile. This allows the attacker to compromise data integrity on target backends by masquerading as an administrative process. For instance, if the target transport utilizes SPIFFE workload certificates to prove microservice identity, the attacker can spoof this identity to access restricted internal components.

Furthermore, because the vulnerability allows the extraction of trust context via downstream service binding, it completely subverts the isolation model expected in multi-tenant environments. Although the attacker cannot directly read the raw certificate private keys from the file provider, they can route arbitrary TCP streams that use these keys, rendering the logical segregation of the Kubernetes cluster ineffective.

The primary remediation path is to upgrade the Traefik controller to a non-vulnerable version. Organizations running the 3.6 branch must upgrade to version 3.6.23 or higher, while those on the 3.7 branch must upgrade to 3.7.7 or higher. These patched releases correctly validate all TCP serversTransport references against the configured crossProviderNamespaces allowlist, halting the processing of unauthorized resources.

If upgrading immediately is not possible, administrators should actively review their static Traefik configurations. If the crossProviderNamespaces attribute is omitted or nil, Traefik defaults to a permissive configuration where all cross-provider boundaries are allowed. Ensuring this setting is defined and restricted to only administrative namespaces (e.g., kube-system or traefik-admin) is a vital step in reducing the exposure window.

To proactively audit existing environments for exploitation, security engineers can execute a target scan using kubectl. The following command extracts all IngressRouteTCP configurations across the cluster and filters for references to file-provider transports. The results can then be manually compared against the list of authorized namespaces:

kubectl get ingressroutetcp --all-namespaces -o json | jq '.items[] | select(.spec.routes[].services[].serversTransport | strings | contains("@file")) | {name: .metadata.name, namespace: .metadata.namespace, transport: .spec.routes[].services[].serversTransport}'