GHSA-qh9r-j7rp-4x2m: Critical severity go/github.com/openchoreo/openchoreo vulnerability
Summary The OpenChoreo control-plane cluster-gateway served its caller-facing management APIs on the same network listener that accepts data-plane agent connections. In the multi-cluster topology that listener is published outside the cluster, and the management APIs did not authenticate the calling client. A party able to reach the listener could therefore invoke privileged data-plane operations without authenticating and without passing through the OpenChoreo API server's authorization.
Impact An attacker who can reach the externally published cluster-gateway endpoint can perform data-plane operations normally restricted to the OpenChoreo API server and gated by its authorization — including proxying the data plane's Kubernetes API and executing commands inside workload pods. This can result in full compromise of workloads on the affected data plane (disclosure, tampering, and denial of service).
The exposure applies to the multi-cluster / remote data-plane topology, where the cluster-gateway is published outside the cluster so remote data-plane agents can connect. That same externally reachable listener also served the caller-facing management APIs, which did not authenticate the caller. Deployments that do not publish the cluster-gateway outside the cluster are not affected.
Patches Fixed in 1.0.2, 1.1.2, and 1.2.0. The fix moves the caller-facing management APIs onto a separate internal listener that is not published outside the cluster, leaving only the agent-connection endpoint on the externally reachable listener. Upgrading is non-disruptive — no data-plane agent or configuration changes are required beyond the standard chart upgrade. Upgrade path: 1.1.x → 1.1.2, 1.0.x and earlier → 1.0.2, 1.2 line → 1.2.0.
Workarounds If you cannot upgrade immediately: - If you do run remote data planes, restrict reachability of the external gateway endpoint to known data-plane source addresses only (firewall / gateway-level allowlisting).
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.1.2 - Upgrade
Upgrade
go/github.com/openchoreo/openchoreoto 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.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
If running remote data planes and the external cluster-gateway listener is reachable outside the cluster, restrict firewall/gateway reachability of the externally published cluster-gateway endpoint to known data-plane source addresses only (allowlisting).
Event History
Frequently Asked Questions
Which deployments are exposed?
The exposure applies to the multi-cluster or remote data-plane topology where cluster-gateway is published outside the cluster for remote data-plane agent connections. Deployments that do not externally publish that listener are not identified as affected by the available information.
Does an attacker need OpenChoreo credentials or API-server authorization?
No. A party that can reach the externally published cluster-gateway listener can invoke the affected management APIs without authenticating and without passing through OpenChoreo API-server authorization.
What could an unauthenticated attacker do through the exposed endpoint?
They can perform privileged data-plane operations, including proxying the data plane Kubernetes API and executing commands in workload pods. This can lead to disclosure, tampering, and denial of service across workloads on the affected data plane.