CVE-2026-18673: Kuma Data Plane Information Disclosure

CVE-2026-18673 Overview

CVE-2026-18673 is an information disclosure vulnerability [CWE-200] in Kuma's data plane proxy (kuma-dp). When operators configure the Envoy admin API on a Unix domain socket, which is the default, the readiness service on TCP port 9902 binds to all interfaces and forwards nearly the entire Envoy admin API to any caller. No authentication is required.

An attacker with network reach to port 9902, such as a neighboring pod on the cluster network, can read Envoy and data plane configuration. Exposed data includes config dumps, cluster and listener lists, stats, and the mesh trust bundle. Destructive Envoy admin operations remain blocked and private keys are not exposed.

Critical Impact
Adjacent-network attackers can read Envoy configuration, cluster and listener details, runtime stats, and the mesh trust bundle from any kuma-dp instance reachable on TCP port 9902 without credentials.

Affected Products

Kuma service mesh kuma-dp data plane proxy (default configuration with Envoy admin API on Unix domain socket)
Kong Mesh distributions built on affected Kuma versions
Deployments where TCP port 9902 is reachable from other workloads on the cluster network

Discovery Timeline

2026-08-12 - CVE-2026-18673 published to NVD
2026-08-12 - Last updated in NVD database

Technical Details for CVE-2026-18673

Vulnerability Analysis

Kuma's kuma-dp sidecar runs Envoy alongside a small control surface. The Envoy admin API is placed on a Unix domain socket by default, which is intended to limit access to processes inside the same pod or host. The kuma-dp readiness service listens on TCP port 9902 and binds to 0.0.0.0, making it reachable from any network peer that can route to the pod.

The readiness handler proxies most admin API paths through to Envoy. Because the readiness listener does not enforce authentication, any caller that reaches port 9902 receives responses from the underlying admin API. This defeats the isolation that the Unix domain socket configuration was intended to provide.

Root Cause

The root cause is a missing authorization check [CWE-200] on the readiness endpoint combined with a broad interface binding. The readiness service was designed to expose liveness and readiness signals but instead forwards config dumps, cluster and listener registries, statistics, and the mesh trust bundle. Sensitive material such as private keys and destructive admin actions are filtered, but the remaining data is sufficient for reconnaissance.

Attack Vector

Exploitation requires only network access to port 9902 of a target kuma-dp pod. In a typical Kubernetes deployment, any pod on the cluster network can issue HTTP GET requests to the readiness port and retrieve configuration data. Attackers can enumerate mesh topology, upstream services, TLS trust anchors, and runtime metrics. No credentials, session state, or user interaction are required.

Refer to the GitHub Security Advisory GHSA-r9pv-x3pm-4r2w and Kuma Pull Request #17317 for the technical fix details.

Detection Methods for CVE-2026-18673

Indicators of Compromise

HTTP GET requests to port 9902 targeting admin API paths such as /config_dump, /clusters, /listeners, /stats, or /certs from unexpected source pods
Unusually high request volume to the readiness endpoint from workloads that are not part of the platform or observability stack
Egress from compromised or unauthorized pods followed by lateral requests to sidecar port 9902 across multiple namespaces

Detection Strategies

Inspect network policy logs and service mesh access logs for cross-namespace traffic to TCP 9902 on data plane pods
Compare source IPs of 9902 traffic against an allowlist of health-checking components (kubelet, load balancer probes)
Alert on responses larger than a typical readiness payload, which indicates admin API content being returned

Monitoring Recommendations

Enable flow logs (VPC flow logs, Cilium Hubble, or eBPF-based observability) to record east-west connections to sidecar ports
Ingest Kubernetes audit logs and pod network telemetry into a centralized data lake for correlation across namespaces
Track baseline request patterns to kuma-dp ports and alert on deviations in path, method, or client identity

How to Mitigate CVE-2026-18673

Immediate Actions Required

Upgrade kuma-dp and Kong Mesh to a version that includes the fixes from Kuma Pull Request #17317 and Kuma Pull Request #17418
Apply Kubernetes NetworkPolicy or equivalent controls to restrict inbound traffic to TCP 9902 to health-checking sources only
Audit recent traffic to port 9902 across the cluster to identify any prior unauthorized access

Patch Information

Refer to the Kong Mesh Changelog and the upstream GitHub Security Advisory GHSA-r9pv-x3pm-4r2w for the list of fixed versions. The patches restrict which admin API paths the readiness endpoint forwards and tighten the exposure of the readiness service.

Workarounds

Bind the readiness service to 127.0.0.1 or the pod-local interface where supported by the deployment configuration
Enforce a default-deny NetworkPolicy in mesh namespaces and explicitly allow probes from kubelet and load balancer address ranges
Segment pods by workload identity so that only trusted probes and mesh control plane components can reach data plane sidecar ports

bash

# Example Kubernetes NetworkPolicy restricting access to kuma-dp readiness port 9902
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-kuma-dp-readiness
  namespace: kuma-system
spec:
  podSelector:
    matchLabels:
      app: kuma-dp
  policyTypes:
    - Ingress
  ingress:
    - from:
        - ipBlock:
            cidr: 169.254.0.0/16  # replace with kubelet or probe source range
      ports:
        - protocol: TCP
          port: 9902