GPU VulnDB

Database/Container, Kubernetes & orchestration

Kuma: Universal-mode dataplane skips TLS verification, exposing its token to proxy takeover

CVSS 5.8CVE-2026-52724Container, Kubernetes & orchestrationcurated

Impact

In Universal (non-Kubernetes) mode, kuma-dp connecting to an HTTPS control plane disables TLS peer verification when neither --ca-cert-file nor KUMA_CONTROL_PLANE_CA_CERT is set. The dataplane authentication token then travels over an unverified channel, so an on-path attacker can capture it, impersonate the control plane, hand the proxy a forged bootstrap configuration and take the proxy over - which means controlling what traffic that workload sends and receives inside the mesh. For a fleet that runs mesh sidecars on bare-metal or VM GPU nodes alongside Kubernetes, those Universal-mode dataplanes are exactly the ones affected; standard Kubernetes installs from kumactl install control-plane or the official Helm chart are not, because the mutating webhook injects the CA cert. Scope change is rated high across confidentiality, integrity and availability.

Who can reach it

An attacker positioned on the network path between a Universal-mode kuma-dp and the control plane; no authentication needed, but the path position and the missing CA configuration are both required.

What to do

Upgrade Kuma to 2.7.26, 2.9.16, 2.11.14, 2.12.11 or 2.13.7 depending on your branch, and explicitly set --ca-cert-file or KUMA_CONTROL_PLANE_CA_CERT on every Universal-mode dataplane. Rolling the fix means restarting kuma-dp on each affected host, a per-workload sidecar restart rather than a node reboot. Treat any token that traversed an unverified connection as potentially exposed and rotate the dataplane tokens.

References

Related entries

All Container, Kubernetes & orchestration entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.