OpenChoreo Cluster-Gateway Flaw Allowed Unauthenticated Data-Plane Takeover (CVE-2026-73843)

OpenChoreo has disclosed a critical vulnerability, CVE-2026-73843 (CVSS 9.6), in its control-plane cluster-gateway component. A public proof-of-concept is reported to be available.

What happened

According to the GitHub Security Advisory (GHSA-qh9r-j7rp-4x2m), the cluster-gateway exposed its caller-facing management APIs on the same network listener used for data-plane agent connections. In multi-cluster/remote data-plane deployments, that listener is published outside the cluster so remote agents can reach it — but the management APIs on it did not authenticate callers. As a result, anyone able to reach the externally published listener could invoke privileged data-plane operations without authentication and without going through the OpenChoreo API server's authorization layer.

Why it matters

Per the advisory, an attacker with network access to the exposed gateway endpoint could proxy the data plane's Kubernetes API and execute commands inside workload pods — operations normally gated by the API server. This can lead to full compromise of workloads on the affected data plane, including disclosure, tampering, and denial of service. The exposure is scoped to multi-cluster/remote data-plane topologies where the cluster-gateway is published externally; single-cluster deployments that don't publish this listener outside the cluster are not affected.

What defenders should do now

• Identify any OpenChoreo control planes running the multi-cluster/remote data-plane topology and confirm whether the cluster-gateway listener is reachable from outside the cluster.
• Upgrade per the vendor's path: 1.0.x and earlier → 1.0.2, 1.1.x → 1.1.2, 1.2 line → 1.2.0. The advisory states the fix moves management APIs to a separate internal listener and that upgrading is non-disruptive.
• If immediate upgrade isn't possible, restrict reachability of the external gateway endpoint to known data-plane source addresses via firewall/gateway-level allowlisting, as recommended in the advisory.
• Review logs/network traffic to the externally published cluster-gateway endpoint for connections from unexpected sources, and check for signs of unauthorized Kubernetes API proxying or pod exec activity on affected data planes.

Developing intel

This is same-day, developing intelligence based solely on the vendor's advisory; details such as in-the-wild exploitation are not yet confirmed. Organizations running OpenChoreo should consult the original advisory directly: GHSA-qh9r-j7rp-4x2m.