PT-2026-60682 · Go · Github.Com/Kumahq/Kuma+1

CVE-2026-52724

·

Published

2026-07-16

·

Updated

2026-07-16

CVSS v4.0

5.8

Medium

VectorAV:A/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H
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

Improper Certificate Validation

Found an issue in the description? Have something to add? Feel free to write us 👾
dbugs@ptsecurity.com

Weakness Enumeration

CWE-295

Related Identifiers

CVE-2026-52724
GHSA-WVMP-6R4V-J6CV

Affected Products

Github.Com/Kumahq/Kuma
Github.Com/Kumahq/Kuma/V2