GHSA-rh53-xvx2-j327: SSRF
Summary
The OpenChoreo control-plane cluster-gateway exposes internal management APIs (/api/proxy/, /api/exec/, /api/wirelogs/) that tunnel requests through to connected data planes' Kubernetes APIs, but the internal listener authenticates no caller. Its request validator permits mutating HTTP methods and reads of Secrets in tenant namespaces (only kube-system Secrets are blocked), so although the client library documents these requests as "read-only," the server enforces no such restriction. Any party able to reach the internal listener can — with no client certificate or token — read Secrets in any tenant namespace, create/modify/delete workloads, and exec into pods across every connected data plane.
Impact
An attacker with network access to the cluster-gateway internal listener obtains tunneled access to every connected data plane's Kubernetes API with no caller-level access control. Across all connected data planes, this allows:
- Secret disclosure — reading any Secret outside kube-system in any tenant namespace (database credentials, cloud/KMS keys, TLS private keys), independent of any workload ServiceAccount permissions. - Workload tampering or destruction — creating, modifying, or deleting Deployments, Services, and other resources. - Pod command execution inside workload pods via /api/exec/.
This is also the missing second authorization layer behind GHSA-52gf-6rpq-fgmx (the openchoreo-api exec/wirelogs cross-project authorization bypass): because the gateway provides no compensating authorization, that bypass — and any other authz gap or SSRF that reaches the internal API — reaches the data-plane Kubernetes API unchecked.
Direct exploitability depends on the network isolation of the internal listener, which is not fixed in source. Where the internal port is reachable by untrusted workloads with no restrictive NetworkPolicy — and with impact landing in a separate data-plane cluster — this is Critical; it is scored conservatively as High otherwise.
Patches
Fixed in 1.0.3, 1.1.3, and 1.2.0. Upgrade path: 1.1.x → 1.1.2, 1.0.x and earlier → 1.0.2, 1.2.0-rc1 line → 1.2.0.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/github.com/openchoreo/openchoreoto a version that resolves this vulnerability.Fixed in 1.2.0 - Upgrade
Upgrade
go/github.com/openchoreo/openchoreoto a version that resolves this vulnerability.Fixed in 1.1.3 - Upgrade
Upgrade
go/github.com/openchoreo/openchoreoto a version that resolves this vulnerability.Fixed in 1.0.3 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 1.0.2 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 1.1.2 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 1.2.0 - Compensating control
Ensure the OpenChoreo cluster-gateway internal listener/management APIs are not reachable by untrusted workloads; apply network isolation so that /api/proxy/, /api/exec/, and /api/wirelogs/ cannot be reached from untrusted sources unless authenticated and authorized.
Event History
Frequently Asked Questions
What does an attacker need to exploit this issue?
The attacker needs network access to the cluster-gateway internal listener. No client certificate or token is required by that listener.
Which environments and resources are exposed?
Every data plane connected through the affected cluster-gateway is in scope. An attacker can read Secrets in tenant namespaces, while Secrets in the kube-system namespace are blocked by the validator.
What actions can an unauthenticated reachable caller perform?
A caller can tunnel requests to connected data planes' Kubernetes APIs, including creating, modifying, or deleting workloads and executing commands in pods. These capabilities are not limited by the ServiceAccount permissions of workloads in the target data plane.