Prior to the released fixes, Kuma Universal mode dataplanes that were started without a CA certificate or without setting the KUMA_CONTROL_PLANE_CA_CERT environment variable would connect to an HTTPS control plane without performing TLS peer verification. The dataplane therefore sends its authentication token over an unverified connection. An attacker following the traffic could capture this token, impersonate the control plane, and inject a forged bootstrap configuration, effectively taking over the proxy. Standard Kubernetes installations created with kumactl install control‑plane or the official Helm chart are not affected because the admission webhook injects the control‑plane CA certificate into each sidecar, enforcing TLS verification.

Affected products are Kuma v2.7.x, 2.9.x, 2.11.x, 2.12.x, and 2.13.x versions earlier than 2.7.26, 2.9.16, 2.11.14, 2.12.11, and 2.13.7 respectively. Standard Kubernetes installations created by kumactl install control‑plane or the official Helm chart are not impacted because the admission webhook automatically injects the control‑plane CA certificate into each sidecar, ensuring TLS verification is performed.

The CVSS score of 5.8 indicates moderate severity. The EPSS score of less than 1% suggests a low probability of exploitation. The vulnerability is not listed in CISA KEV, so there is no evidence yet of widespread exploitation. An attacker only needs to intercept traffic to a dataplane that is not enforcing TLS verification, which can be feasible in shared or compromised network environments. Thus, the exploit remains attainable whenever the dataplane omits a CA certificate and the network path is vulnerable.