CVE-2026-18673 in Kuma
Summary
by MITRE • 08/12/2026
When kuma-dp is configured with the Envoy admin API on a Unix domain socket, which is the default, its readiness service on TCP port 9902 - bound to all interfaces - forwards almost the entire Envoy admin API to any caller that can reach the port, with no authentication.
An attacker with network access to a data plane's port 9902, for example another pod on the cluster network, can read Envoy and data plane configuration without credentials: config dumps, cluster and listener lists, stats, and the mesh trust bundle. Exposure is read-only - destructive Envoy admin actions are blocked and private keys are not exposed.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/12/2026
The vulnerability described represents a critical security flaw in the kuma-dp proxy implementation where the readiness service operates on TCP port 9902 without proper authentication mechanisms. This configuration exposes sensitive operational data through an unauthenticated administrative interface that is accessible to any network entity capable of reaching the designated port. The default deployment setting binds this service to all network interfaces, significantly expanding the attack surface and eliminating any network-based access controls that might otherwise provide basic protection.
The technical implementation flaw stems from the improper separation of administrative functionality from operational services within the kuma data plane proxy. When Envoy admin API is configured to use Unix domain sockets for internal communication, this provides a secure local endpoint that should remain isolated from external network access. However, the readiness service on port 9902 creates an unintended network exposure that bypasses these security boundaries. This design pattern violates fundamental principles of least privilege and network segmentation that are essential for containerized environments and microservices architectures. The vulnerability aligns with CWE-284 which addresses improper access control, specifically focusing on inadequate authorization mechanisms for administrative interfaces.
The operational impact of this vulnerability extends beyond simple information disclosure to potentially enable more sophisticated attacks within a compromised cluster environment. An attacker who gains access to port 9902 can obtain comprehensive insights into the data plane's configuration including detailed envoy settings, active clusters and listeners, real-time statistics, and the mesh trust bundle that contains certificate information. While destructive operations are blocked and private keys remain protected, the exposure of configuration data and operational metrics provides attackers with valuable intelligence for further exploitation. This information could be leveraged to identify service dependencies, understand traffic patterns, locate potential attack vectors, and craft more targeted attacks against other services within the mesh.
The security implications become particularly severe in containerized environments where pods share network namespaces or when clusters lack proper network policies to restrict inter-pod communication. This vulnerability effectively transforms a local administrative interface into a remotely accessible reconnaissance tool that can be exploited by any entity with network access to the kuma-dp instance, including malicious actors within the same cluster. The exposure of mesh trust bundle information specifically threatens the integrity of certificate-based authentication systems and could potentially enable man-in-the-middle attacks or certificate forgery attempts. Organizations should consider this vulnerability in alignment with ATT&CK technique T1083 which covers discovery of file and directory permissions, and T1566 which addresses credential access through network services.
Effective mitigation strategies must address both the immediate exposure and the underlying architectural issue. The most direct approach involves implementing proper network segmentation controls to restrict access to port 9902, ensuring that only authorized components can reach this administrative interface. Organizations should enforce strict network policies using tools like kubernetes network policies or service mesh-specific access control mechanisms to limit which pods can communicate with the readiness service. Additionally, administrators should consider disabling the readiness service entirely when it is not required for operational purposes, or reconfiguring the service to use authentication mechanisms such as mutual TLS or API keys. The long-term solution requires architectural changes that ensure administrative interfaces remain isolated from externally accessible network endpoints while maintaining necessary operational functionality for monitoring and health checks.