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
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
Update github.com/kumahq/kuma/v2 to 2.7.26; github.com/kumahq/kuma/v2 to 2.9.16; github.com/kumahq/kuma/v2 to 2.11.14; github.com/kumahq/kuma/v2 to 2.12.11; github.com/kumahq/kuma/v2 to 2.13.7 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scankuma-dp connects to control plane without verifying TLS certificate when no CA is configured affects github.com/kumahq/kuma (go), github.com/kumahq/kuma/v2 (go), github.com/kumahq/kuma/v2 (go), github.com/kumahq/kuma/v2 (go), github.com/kumahq/kuma/v2 (go), github.com/kumahq/kuma/v2 (go). Severity is medium. 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
AI coding agents often install or upgrade packages automatically in go. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| github.com/kumahq/kumago | <=1.8.1 | Not reported |
| github.com/kumahq/kuma/v2go | <2.7.26 | 2.7.26 |
| github.com/kumahq/kuma/v2go | >=2.8.0,<2.9.16 | 2.9.16 |
| github.com/kumahq/kuma/v2go | >=2.10.0,<2.11.14 | 2.11.14 |
| github.com/kumahq/kuma/v2go | >=2.12.0,<2.12.11 | 2.12.11 |
| github.com/kumahq/kuma/v2go | >=2.13.0,<2.13.7 | 2.13.7 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate github.com/kumahq/kuma/v2 to 2.7.26; github.com/kumahq/kuma/v2 to 2.9.16; github.com/kumahq/kuma/v2 to 2.11.14; github.com/kumahq/kuma/v2 to 2.12.11; github.com/kumahq/kuma/v2 to 2.13.7 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scankuma-dp connects to control plane without verifying TLS certificate when no CA is configured affects github.com/kumahq/kuma (go), github.com/kumahq/kuma/v2 (go), github.com/kumahq/kuma/v2 (go), github.com/kumahq/kuma/v2 (go), github.com/kumahq/kuma/v2 (go), github.com/kumahq/kuma/v2 (go). Severity is medium. 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
AI coding agents often install or upgrade packages automatically in go. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| github.com/kumahq/kumago | <=1.8.1 | Not reported |
| github.com/kumahq/kuma/v2go | <2.7.26 | 2.7.26 |
| github.com/kumahq/kuma/v2go | >=2.8.0,<2.9.16 | 2.9.16 |
| github.com/kumahq/kuma/v2go | >=2.10.0,<2.11.14 | 2.11.14 |
| github.com/kumahq/kuma/v2go | >=2.12.0,<2.12.11 | 2.12.11 |
| github.com/kumahq/kuma/v2go | >=2.13.0,<2.13.7 | 2.13.7 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard