CVE-2026-102340: 
vulnerability analysis and mitigation

CVE-2026-102340 is an authorization bypass vulnerability in Telepresence's Traffic Manager gRPC API that allows any pod with cluster-network access to register in arbitrary managed namespaces, create service intercepts, and exfiltrate victim pod environment secrets without Kubernetes RBAC verification. It affects all versions of github.com/telepresenceio/telepresence prior to v2.31.0. The vulnerability was disclosed on November 4, 2026, and fixed in v2.31.0 released July 22, 2026. It carries a CVSS v3.1 base score of 8.5 (High) (GitHub Advisory, Red Hat CVE).

The root cause is a combination of missing authentication (CWE-306) and missing authorization (CWE-862) in the Traffic Manager's gRPC server (pkg/grpc/server/server.go), which is started with no authentication interceptor and uses plaintext transport (insecure.NewCredentials()). The ArriveAsClient RPC stores a caller-supplied Namespace field after only checking whether the namespace is in the Traffic Manager's watchlist via ManagesNamespace() — no SubjectAccessReview, bearer token, or kubeconfig verification is performed. Similarly, CreateIntercept calls managedTargetNamespace() which also only checks ManagesNamespace() on the target namespace, never verifying that the target matches the client's registered namespace or that the session holds appropriate Kubernetes RBAC permissions, allowing a session registered in namespace A to intercept namespace B as long as B is also watched (GitHub Advisory, Fix Commit).

An attacker controlling any pod with network access to the Traffic Manager on port 8081 can register as a client in any managed namespace, create intercepts against services in namespaces they have no RBAC access to, and receive all intercepted traffic along with the victim pod's complete container environment — including database passwords, API keys, and Kubernetes service account tokens. In the default cluster-wide Traffic Manager deployment, all namespaces are managed, meaning the blast radius extends to every workload in the cluster. There is no audit trail on the victim namespace, and secrets mounted as environment variables are exfiltrated silently (GitHub Advisory).

No public proof-of-concept exploit code has been published, and there is no evidence of in-the-wild exploitation at this time (Feedly). The GitHub security advisory includes a detailed PoC code snippet demonstrating the attack using standard gRPC client calls, which significantly lowers the barrier for exploitation by any attacker with pod-level access to the cluster network. The EPSS score is approximately 0.0028 (low probability of near-term exploitation). The vulnerability is not listed in the CISA KEV catalog. No specific threat actor attribution has been reported.

1. Reconnaissance: Identify a Telepresence Traffic Manager deployment in the target Kubernetes cluster by querying for the traffic-manager service (e.g., kubectl get svc -A | grep traffic-manager) or by scanning cluster-internal DNS for traffic-manager.ambassador:8081.
2. Gain pod access: Obtain execution within any pod in the cluster (e.g., via a compromised application container, a misconfigured admission policy, or a separate vulnerability).
3. Connect to the gRPC API: From within the pod, establish a plaintext gRPC connection to traffic-manager.ambassador:8081 using grpc.WithTransportCredentials(insecure.NewCredentials()) — no credentials are required.
4. Register in a target namespace: Call ArriveAsClient with a ClientInfo struct specifying the desired target namespace (e.g., payments). The only gate is whether the namespace is in the Traffic Manager's watchlist; if it is, a valid SessionInfo with a SessionId is returned.
5. Create a service intercept: Call CreateIntercept with the returned session and an InterceptSpec targeting a service in the chosen namespace (e.g., payments-api). The Traffic Manager does not verify RBAC for the session.
6. Receive intercepted traffic and secrets: The Traffic Manager redirects traffic destined for the target service to the attacker's pod and delivers the victim pod's full container environment (including secrets, tokens, and API keys) via intercept.Environment (GitHub Advisory).

• Network: Unexpected inbound gRPC connections to the Traffic Manager service on port 8081 from pods that are not legitimate Telepresence clients or agents; unusual outbound connections from the Traffic Manager pod to unexpected pod IPs.
• Logs: Traffic Manager logs showing ArriveAsClient calls from unexpected pod identities or namespaces; CreateIntercept log entries for namespaces that do not correspond to the connecting client's expected namespace; warning log entries such as intercept "..." in namespace ...: ... (not enforced) after upgrading to v2.31.0 in permissive mode.
• Kubernetes API: Unexpected TokenReview or SubjectAccessReview API calls originating from the Traffic Manager (post-patch, these are expected; pre-patch their absence is normal — any intercept creation from an unrecognized client is suspicious).
• Process/Environment: Evidence of environment variable exfiltration from intercepted pods, such as secrets or tokens appearing in unexpected locations or being used from unfamiliar source IPs (GitHub Advisory).

Upgrade Telepresence to version 2.31.0 or later, which introduces mandatory caller authentication via Kubernetes TokenReviews and RBAC-based intercept authorization via SubjectAccessReviews (Release PR). After upgrading, set the Helm value security.authentication.mode to enforcing to actively reject unauthenticated callers; the default permissive mode validates and logs but does not reject, preserving backward compatibility. As an immediate network-level workaround, apply Kubernetes NetworkPolicies to restrict pod-to-pod access to the Traffic Manager service on port 8081 to only trusted cluster components (legitimate Telepresence clients and agents). Additionally, review and tighten Kubernetes RBAC to limit which service accounts and pods can reach the Traffic Manager network endpoint (GitHub Advisory, Auth Mode Commit).

The vulnerability was reported by security researcher 0xVijay and published as GitHub Security Advisory GHSA-j8j4-rw65-56r6 (GitHub Advisory). The fix was developed by Telepresence maintainer Thomas Hallgren (thallgren), who implemented a comprehensive authentication and authorization overhaul in v2.31.0, including opt-in enforcement mode to avoid breaking existing installations. Red Hat tracked the issue for their OpenShift-related products (Red Hat CVE), and the NixOS security tracker also flagged the issue for the telepresence2 package (Release PR). No significant broader media coverage or social media discussion has been identified.