GHSA-wvmp-6r4v-j6cv kuma-dp connects to control plane without verifying TLS certificate when no CA is configured

• Go github.com/kumahq/kuma/v2: < 2.7.26 → fixed in 2.7.26 • Go github.com/kumahq/kuma/v2: >= 2.8.0, < 2.9.16 → fixed in 2.9.16 • Go github.com/kumahq/kuma/v2: >= 2.10.0, < 2.11.14 → fixed in 2.11.14 • Go github.com/kumahq/kuma/v2: >= 2.12.0, < 2.12.11 → fixed in 2.12.11 • Go github.com/kumahq/kuma/v2: >= 2.13.0, < 2.13.7 → fixed in 2.13.7 • Go github.com/kumahq/kuma: <= 1.8.1 (no fix yet)

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. The dataplane authentication token is sent over this unverified connection Impact An on-path attacker can intercept the dataplane authentication token and impersonate the control plane to the data plane, allowing them to inject a forged bootstrap configuration and take over the proxy Affected configurations • Universal mode `kuma-dp` started against an HTTPS control plane without `--ca-cert-file` (or `KUMA_CONTROL_PLANE_CA_CERT` unset) Not affected • Kubernetes installs done through the standard installers (`kumactl install control-plane` or the official 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 Workarounds 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; the patched releases will verify successfully against the operating system trust store with no further configuration Resources • Fix: https://github.com/kumahq/kuma/pull/16777