Database/Container, Kubernetes & orchestration

kuma-dp: readiness port 9902 proxies the Envoy admin API to the pod network with no authentication

CVE-2026-18673Container, Kubernetes & orchestrationcurated

Impact

With the Envoy admin API on a Unix socket - the default - kuma-dp's readiness service on TCP 9902 binds all interfaces and forwards nearly the whole admin API to any caller that reaches it, unauthenticated. That yields config dumps, cluster and listener inventories, stats, and the mesh trust bundle for every data plane in the mesh. In a GPU cluster where the service mesh fronts inference endpoints and model-registry traffic, this hands a co-tenant pod a full map of internal services, their routing, and the mesh's trust anchors - useful reconnaissance for lateral movement even though the exposure is read-only. Destructive Envoy admin actions are blocked and private keys are not exposed.

Who can reach it

Any workload with network reach to a data plane pod's port 9902 - in practice any other pod on the cluster network, since NetworkPolicy rarely covers this port. No credentials required.

What to do

Upgrade Kong Mesh / Kuma to a release carrying the fixes in kumahq/kuma PRs 17317 and 17418 and roll the data planes so every kuma-dp sidecar restarts; the control plane alone is not enough. As an immediate mitigation, apply a NetworkPolicy restricting inbound 9902 to the kubelet or the health-check source, or bind the readiness service to localhost where your deployment allows it.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-18673 https://github.com/kumahq/kuma/security/advisories/GHSA-r9pv-x3pm-4r2w https://github.com/kumahq/kuma/pull/17317 https://github.com/kumahq/kuma/pull/17418

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.