CVE-2026-102340 in Telepresence
Summary
by MITRE • 11/04/2026
Telepresence enables local development against a remote Kubernetes or OpenShift cluster. Prior to 2.31.0, the Traffic Manager gRPC API on port 8081 accepts unauthenticated cluster-network callers, ArriveAsClient stores a caller-supplied Namespace using only the ManagesNamespace manager watchlist check, and CreateIntercept can target any managed namespace without checking the session's Kubernetes RBAC. An attacker operating any pod with network access to the manager can register in an arbitrary managed namespace, create service intercepts, receive intercepted traffic, and obtain the victim pod's complete container environment, including secrets, tokens, and API keys. The default cluster-wide deployment manages all namespaces. This vulnerability is fixed in 2.31.0.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/04/2026
The Telepresence tool facilitates local development by allowing developers to interact with remote Kubernetes or OpenShift clusters through a traffic management system. Prior to version 2.31.0, the architecture of this system contained critical security flaws within its gRPC API endpoint on port 8081 that fundamentally undermined access control mechanisms. The core issue stems from insufficient authentication and authorization checks during the initialization of client sessions and the creation of service intercepts. Specifically, the Traffic Manager accepts connections from any caller with network access to the manager without requiring valid credentials or tokens. This lack of mutual TLS or token-based authentication allows an attacker operating a compromised pod within the cluster to establish a direct connection to the management interface.
Once connected, the vulnerability manifests in two distinct phases that enable privilege escalation and data exfiltration. First, when registering as a client via the ArriveAsClient function, the system relies solely on a ManagesNamespace manager watchlist check rather than validating the caller's identity or permissions against Kubernetes Role-Based Access Control RBAC policies. This allows an attacker to register in any namespace that is managed by Telepresence, regardless of whether they have legitimate access rights within that specific namespace. Second, during the creation of intercepts via CreateIntercept, the system fails to verify if the session holder has permission to target the specified service or namespace. Consequently, an attacker can create intercepts for services in arbitrary namespaces under management without any RBAC validation.
The operational impact of these flaws is severe, leading to a complete compromise of sensitive data within the targeted cluster environments. By successfully registering and creating intercepts, an attacker gains the ability to receive all traffic destined for victim pods. This interception capability allows the attacker to inspect network payloads in plaintext or decrypt them if applicable, but more critically, it provides access to the container environment variables of the target pod. In Kubernetes deployments, this often includes sensitive information such as API keys, database credentials, service account tokens, and other secrets mounted into containers for application configuration. Since Telepresence is frequently deployed with cluster-wide permissions by default, an attacker can potentially enumerate and intercept traffic from any namespace in the entire cluster, leading to widespread data exposure across multiple applications and services.
This vulnerability aligns with CWE-287 Improper Authentication and CWE-928 Privilege Escalation due to Incorrect Authorization, as it involves both a failure to verify identity and a failure to enforce access controls based on user roles or permissions. From an ATT&CK perspective, this flaw facilitates Initial Access through compromised workloads and enables Credential Access by extracting secrets from container environments. It also supports Lateral Movement within the cluster if intercepted traffic reveals internal service endpoints or authentication mechanisms that can be leveraged further. The severity is exacerbated by the common deployment pattern where Telepresence manages all namespaces, effectively granting any pod with network reachability to port 8081 full visibility into sensitive operational data.
To mitigate this risk, organizations must upgrade immediately to version 2.31.0 or later, which addresses these authentication and authorization gaps in the Traffic Manager API. In environments where upgrading is not immediately feasible, strict network segmentation should be implemented to restrict access to port 8081 only to trusted administrative workloads using IP allowlisting at the network policy level. Additionally, administrators should review Telepresence deployment configurations to ensure that cluster-wide permissions are minimized and that RBAC policies in Kubernetes are tightly coupled with application-specific needs rather than broad management roles. Regular auditing of pod-to-pod communication patterns can also help detect unauthorized attempts to connect to internal service ports like 8081 before exploitation occurs.