When kuma-dp is started against an HTTPS control plane and the operator did not pass a CA certificate, the data plane connects with TLS peer verification disabled, and the dataplane authentication token is sent over that unverified connection.
An on-path actor can intercept the dataplane authentication token and impersonate the control plane to the data plane, injecting a forged bootstrap configuration and taking over the proxy.
You are affected if you run universal mode kuma-dp against an HTTPS control plane without --ca-cert-file, or with KUMA_CONTROL_PLANE_CA_CERT unset.
You are not affected if you install on Kubernetes through kumactl install control-plane or the official Kong Mesh Helm chart. In both cases the control plane's mutating admission webhook injects KUMA_CONTROL_PLANE_CA_CERT into every sidecar at pod admission, so each kuma-dp starts with the CA already configured.
Set --ca-cert-file, or KUMA_CONTROL_PLANE_CA_CERT, on every universal mode data plane and point it at the control plane's serving CA. Alternatively terminate the control plane behind a publicly trusted certificate.
Upgrade to Kong Mesh 2.7.26, 2.9.16, 2.11.14, 2.12.11 or 2.13.7, whichever matches your release line. Patched releases fall back to the operating system trust store instead of disabling verification, so a publicly trusted control plane certificate verifies with no further configuration. The 2.14 line shipped after the fix and was never affected.