CVE-2026-102340: Missing Authentication and Authorization in Telepresence Traffic Manager gRPC API

Telepresence is a Cloud Native Computing Foundation (CNCF) tool maintained under telepresenceio/telepresence that enables local development workflows against remote Kubernetes and OpenShift clusters. Its architecture relies on three distinct components: the Telepresence CLI running on developer workstations, the central Traffic Manager deployed inside the cluster, and the Traffic Agent sidecar container injected into target workload pods. The Traffic Manager coordinates state between connected clients and deployed agents, exposing a gRPC server over TCP port 8081 within the cluster network.

Prior to version 2.31.0, the Traffic Manager gRPC service operated without authentication or authorization controls, tracked under CVE-2026-102340 (and GitHub Security Advisory GHSA-j8j4-rw65-56r6). This vulnerability encompasses two primary weakness classes: CWE-306 (Missing Authentication for Critical Function) and CWE-862 (Missing Authorization). The gRPC endpoint accepted plaintext HTTP/2 (h2c) connections from any network-reachable pod without verifying bearer tokens or client certificates.

Because the default cluster-wide installation configures the Traffic Manager with cluster-scoped privileges and a watchlist spanning all namespaces, the exposed API represents a critical privilege escalation vector. Any unprivileged pod capable of reaching port 8081 on the Traffic Manager service can claim arbitrary namespaces via the ArriveAsClient RPC and register traffic intercepts on arbitrary services via the CreateIntercept RPC.

Successful exploitation allows an adversary to break namespace isolation boundaries without possessing corresponding Kubernetes Role-Based Access Control (RBAC) permissions. When an intercept is established, the Traffic Manager reroutes live ingress network traffic intended for the victim service to the attacker's pod and transmits the target container's full runtime environment—exposing sensitive Kubernetes Secret mounts, projected ServiceAccount tokens, and application credentials.

The root cause of CVE-2026-102340 lies in the absence of gRPC server authentication interceptors and the omission of Kubernetes API authorization checks during session and intercept lifecycle management. In versions prior to 2.31.0, the server initialization in cmd/traffic/cmd/manager/manager.go instantiated the gRPC listener via server.New(ctx, opts...) using insecure credentials (insecure.NewCredentials()). Neither unary nor stream server interceptors were registered to extract or validate caller identity from incoming request metadata.

When a client initiates a session by invoking the ArriveAsClient RPC method in cmd/traffic/cmd/manager/service.go, it supplies an rpc.ClientInfo protobuf message containing a caller-chosen Namespace string. The Traffic Manager validated this input exclusively against its internal namespace watchlist using s.state.ManagesNamespace(client.Namespace). In standard deployments where the manager watches all namespaces, this check unconditionally returns true for any existing cluster namespace, allowing the caller to bind its session to privileged namespaces such as kube-system or prod without identity verification.

Furthermore, when the client subsequently invokes CreateIntercept, the service.go handler processed the requested rpc.InterceptSpec and directly invoked s.state.AddIntercept(ctx, ciReq). The Traffic Manager did not query the Kubernetes API server via a SubjectAccessReview (authorization.k8s.io/v1) to verify whether the caller possessed RBAC permissions (such as create on the pods/portforward subresource) in the target namespace.

This missing authorization directly exposes sensitive workload data due to how Telepresence synchronizes environment variables. When a Traffic Agent sidecar initializes inside a target pod, it captures the application container's environment map (cn.Environment) and reports it to the Traffic Manager via ArriveAsAgent. Upon processing an unauthorized CreateIntercept call, the Traffic Manager returns this stored environment dictionary in the InterceptInfo response, delivering the target container's secrets directly to the unauthenticated caller.

The remediation for CVE-2026-102340 was implemented across three commits in Pull Request #4217 (04ec3464fe8878fdc96420cdc8036edefa0dc9ae, 6871235b674a6e843908d09696354c4b0f91578c, and 36458b65a010d2b316af48cd90e193ba190785d9). Prior to the patch, the ArriveAsClient and CreateIntercept RPC handlers accepted client claims at face value and only verified whether the target namespace was actively watched by the manager.

// Pre-patch logic in cmd/traffic/cmd/manager/service.go
func (s *service) ArriveAsClient(ctx context.Context, client *rpc.ClientInfo) (*rpc.SessionInfo, error) {
    if val := validateClient(client); val != "" {
        return nil, status.Error(codes.InvalidArgument, val)
    }
    // VULNERABLE: Only checks if the manager watches the namespace, not if the caller has RBAC access
    if !s.state.ManagesNamespace(client.Namespace) {
        return nil, status.Errorf(codes.InvalidArgument, "namespace %s is not managed", client.Namespace)
    }
    return &rpc.SessionInfo{
        SessionId:         string(s.state.AddClient(client, ptypes.TimestampNow())),
        ManagerInstallId: s.state.Id(),
    }, nil
}

To address the missing authentication (CWE-306), commit 04ec3464fe8878fdc96420cdc8036edefa0dc9ae introduced the cmd/traffic/cmd/manager/auth package. This package implements a gRPC server interceptor that extracts bearer tokens from the authorization metadata header and validates them against the Kubernetes TokenReview API (authentication.k8s.io/v1). Validated identities are stored in the request context as an auth.Principal, and results are cached in memory (with a 2-minute TTL for valid tokens and a 10-second TTL for failed validations) to prevent API server exhaustion. For Traffic Agents, the mutating webhook was updated to inject projected service account tokens bound to the traffic-manager audience (agentconfig.ManagerTokenAudience), and ArriveAsAgent now verifies that the token's pod claims match the reported AgentInfo.

To remediate the missing authorization (CWE-862), commits 6871235b674a6e843908d09696354c4b0f91578c and 36458b65a010d2b316af48cd90e193ba190785d9 integrated a SubjectAccessReview authorizer (CanPortForward) into CreateIntercept. The patched code in cmd/traffic/cmd/manager/service.go inspects the authenticated Principal from the context and checks whether the caller has RBAC permission to create the pods/portforward subresource in the target namespace or on the specific workload pods:

@@ -1170,6 +1187,9 @@ func (s *service) CreateIntercept(ctx context.Context, ciReq *rpc.CreateIntercep
 	}
 
 	if err := s.authorizeIntercept(ctx, namespace, spec); err != nil {
+		if s.authMode == auth.ModeEnforcing {
+			return nil, err
+		}
 		clog.Warnf(ctx, "intercept %q in namespace %s: %v (not enforced)", spec.Name, namespace, err)
 	}
 
@@ -1192,10 +1212,16 @@ func (s *service) CreateIntercept(ctx context.Context, ciReq *rpc.CreateIntercep
 func (s *service) authorizeIntercept(ctx context.Context, namespace string, spec *rpc.InterceptSpec) error {
 	p := auth.PrincipalFrom(ctx)
 	if p == nil {
+		if s.authMode == auth.ModeEnforcing {
+			return errors.Errorf(codes.Unauthenticated, "intercept creation requires an authenticated caller")
+		}
 		clog.Debugf(ctx, "caller is unauthenticated; skipping intercept authorization")
 		return nil
 	}

> [!IMPORTANT] > Assessment of Fix Completeness: Commit 36458b65a010d2b316af48cd90e193ba190785d9 introduces three configurable authentication modes via security.authentication.mode: disabled, permissive, and enforcing. To maintain backward compatibility during rolling upgrades, the initial default mode is permissive, which logs warnings on unauthenticated or unauthorized requests but does not block them. Consequently, upgrading to v2.31.0 without explicitly setting the mode to enforcing leaves the cluster vulnerable to exploitation.

Exploiting CVE-2026-102340 requires network access to the Traffic Manager gRPC endpoint on port 8081 within the Kubernetes cluster. No specialized exploit payloads or memory corruption primitives are necessary; an attacker with command execution inside any unprivileged container can abuse the standard Telepresence gRPC protocol definition or an unmodified Telepresence client binary to conduct the attack.

First, the attacker locates the Traffic Manager service (typically reachable via Kubernetes DNS at traffic-manager.ambassador.svc.cluster.local:8081) and opens an unauthenticated HTTP/2 connection. In the first phase of the protocol handshake, the attacker invokes the ArriveAsClient RPC method, passing a crafted ClientInfo structure that specifies a high-value target namespace (such as prod) in the Namespace field. The Traffic Manager verifies that prod is on its watchlist and returns a valid SessionInfo object containing a SessionId.

Next, the attacker uses the acquired SessionId to enumerate active workloads via the WatchAgents stream or directly invokes CreateIntercept. In the CreateInterceptRequest, the attacker provides an InterceptSpec targeting a sensitive service (for example, auth-service in the prod namespace), specifies the tcp or http mechanism, and points the destination host and port to the attacker's pod IP.

If a Traffic Agent sidecar is already present on the target workload—or once the Traffic Manager dynamically injects the mutating webhook sidecar into the victim deployment—the agent connects back to the manager and uploads the target pod's environment variables. The Traffic Manager transitions the intercept state to ACTIVE and returns the InterceptInfo protobuf message to the attacker.

At this stage, the attacker immediately receives the victim container's environment map from the InterceptInfo.Environment field, extracting database connection strings, API keys, and paths or values of mounted Kubernetes secrets. Simultaneously, the Traffic Agent inside the victim pod reconfigures its local tunnel to forward incoming service requests to the attacker's pod, allowing the attacker to inspect, modify, or drop live production traffic.

CVE-2026-102340 carries a CVSS v3.1 base score of 8.5 (High) with the vector string CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N. The Attack Vector is Network (AV:N) and Privileges Required is Low (PR:L), reflecting that an attacker must have access to the internal Kubernetes pod network (such as via a compromised low-privilege pod or SSRF capable of speaking HTTP/2). The Scope is Changed (S:C) because the vulnerability resides in the Traffic Manager control plane component but enables direct compromise of workloads across unrelated namespaces throughout the cluster.

The Confidentiality Impact is High (C:H). By establishing an unauthorized intercept against workloads in sensitive namespaces, an attacker obtains full read access to both live network traffic traversing the target pod and the container's runtime environment variables. In standard Kubernetes architectures, this exposes database credentials, internal microservice API keys, and Kubernetes ServiceAccount tokens, which can subsequently be used to authenticate directly to the Kubernetes API server and escalate privileges across the cluster.

The Integrity Impact is rated Low (I:L) and Availability Impact is None (A:N) in the base CVSS vector, though operational impact in production environments can be severe. Because an attacker can hijack ingress traffic destined for arbitrary services and redirect it to an attacker-controlled pod, the attacker can perform Man-in-the-Middle (MitM) attacks, inject forged responses into internal service-to-service communications, or cause targeted denial of service by blackholing intercepted connections.

From a threat intelligence perspective, CVE-2026-102340 has an EPSS score of 0.00281 (20.78th percentile) and is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Because the vulnerable port (8081) is cluster-internal by default, exploitation is primarily a post-compromise lateral movement and privilege escalation technique (MITRE ATT&CK T1068 and T1552.007) rather than an external initial access vector, unless an organization misconfigures its cluster ingress to expose the Traffic Manager externally.

To remediate CVE-2026-102340, administrators must upgrade both the cluster-side Telepresence Traffic Manager and all developer client binaries to version 2.31.0 or later. Because version 2.31.0 defaults to permissive authentication mode to prevent disruption during phased rollouts, upgrading the software alone is insufficient to block exploitation. Administrators must explicitly configure the Traffic Manager to operate in enforcing mode.

When deploying or upgrading the Traffic Manager via Helm, enable strict authentication enforcement by setting security.authentication.mode in the Helm values file:

security:
  authentication:
    mode: enforcing

Alternatively, if managing the Traffic Manager Deployment manifests directly, set the AUTHENTICATION_MODE environment variable on the manager container:

env:
  - name: AUTHENTICATION_MODE
    value: "enforcing"

Ensure that the Traffic Manager's ClusterRole includes permissions to create tokenreviews (in authentication.k8s.io) and subjectaccessreviews (in authorization.k8s.io), which are automatically provisioned by the updated Helm chart in v2.31.0. Additionally, existing Traffic Agent sidecars injected prior to v2.31.0 must be restarted or re-injected so their pod specifications include the projected traffic-manager audience service account token volume.

For environments where immediate upgrading or enforcement is not feasible, administrators should implement compensating controls using Kubernetes NetworkPolicy resources and namespace scoping. Restrict the Traffic Manager's watchlist to specific non-sensitive development namespaces rather than the entire cluster, and apply a NetworkPolicy in the Traffic Manager's namespace (default ambassador) to restrict ingress on TCP port 8081 strictly to authorized namespaces and pods:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-traffic-manager-access
  namespace: ambassador
spec:
  podSelector:
    matchLabels:
      app: traffic-manager
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: telepresence-authorized-clients
      ports:
        - protocol: TCP
          port: 8081