Most recent entries from all

EUVD-2026-368672

2026-10-09T00:04:30.756033+00:00

EUVD-2026-368672

fkie_cve-2026-52724

2026-10-09T00:04:30.756080+00:00

Kuma is a modern Envoy-based service mesh that can run on every cloud across both Kubernetes and VMs. Prior to 2.7.26, 2.9.16, 2.11.14, 2.12.11, and 2.13.7, Universal mode kuma-dp connections to an HTTPS control plane disable TLS peer verification when --ca-cert-file is not supplied and KUMA_CONTROL_PLANE_CA_CERT is unset. The dataplane authentication token is sent over the unverified connection, allowing an on-path attacker to intercept the token, impersonate the control plane, inject a forged bootstrap configuration, and take over the proxy. Standard Kubernetes installations created by kumactl install control-plane or the official Helm chart are unaffected because the mutating admission webhook injects KUMA_CONTROL_PLANE_CA_CERT into each sidecar. This issue is fixed in versions 2.7.26, 2.9.16, 2.11.14, 2.12.11, and 2.13.7.

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

2026-10-09T00:04:30.756117+00:00

Affected: Go: github.com/kumahq/kuma/v2, Go: github.com/kumahq/kuma

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