OpenChoreo Cluster-Gateway Flaw Lets Unauthenticated Callers Read Secrets and Mutate Kubernetes Workloads Across Data Planes

A newly published GitHub Security Advisory (GHSA-rh53-xvx2-j327, tracked as CVE-2026-73842, CVSS 9.0) reports that OpenChoreo's control-plane cluster-gateway performs no caller authentication on its internal management APIs (/api/proxy/, /api/exec/, /api/wirelogs/). These endpoints tunnel requests through to the Kubernetes APIs of connected data planes. According to the advisory, the request validator allows mutating HTTP methods and reads of Secrets in tenant namespaces — blocking only kube-system Secrets — despite the client library documenting these calls as read-only.

Why It Matters

Per the advisory, any party able to reach the internal listener can, without a client certificate or token, read Secrets (database credentials, cloud/KMS keys, TLS private keys) in any tenant namespace, create/modify/delete workloads such as Deployments and Services, and exec into pods — across every connected data plane. The advisory notes this also removes the compensating control behind a separate authorization bypass (GHSA-52gf-6rpq-fgmx), meaning that bug or any other authz gap/SSRF reaching this internal API would propagate unchecked into data-plane Kubernetes clusters. The advisory states exploitability hinges on how exposed the internal listener is on the network — a factor not addressed by the source fix — rating it Critical where the port is reachable without a restrictive NetworkPolicy, and High otherwise.

What Defenders Should Do Now

• Upgrade OpenChoreo per the advisory's patched versions: 1.1.x → 1.1.2, 1.0.x and earlier → 1.0.2, and 1.2.0-rc1 line → 1.2.0 (or 1.1.3/1.2.0 as applicable).
• Until patched, restrict network reachability to the cluster-gateway's internal listener with NetworkPolicies so only trusted control-plane components can reach it.
• Audit logs/traffic to the internal listener for calls to /api/proxy/, /api/exec/, and /api/wirelogs/ from unexpected sources or namespaces.
• Review tenant-namespace Secrets for signs of unauthorized access, and check for unexpected workload creation, modification, or deletion across connected data planes.
• Treat this as compounding risk alongside GHSA-52gf-6rpq-fgmx if that authorization bypass has not also been remediated.

This is developing intel based on a same-day GitHub Security Advisory; exploitation in the wild has not been confirmed, and a public PoC is referenced but not detailed here. For full technical details, see the original advisory: GHSA-rh53-xvx2-j327.