GHSA-qh9r-j7rp-4x2m is a critical-severity (CVSS 9.6) Missing Authentication vulnerability in github.com/openchoreo/openchoreo. A fix is available for github.com/openchoreo/openchoreo — see the affected versions and patch details below.
OpenChoreo: Unauthenticated access to data-plane operations via OpenChoreo cluster-gateway management APIs
Exploitation Status
No confirmed exploitation observed yet
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-qh9r-j7rp-4x2m.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-qh9r-j7rp-4x2m by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 380,526 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
github.com/openchoreo/openchoreo🐹github.com/openchoreo/openchoreoReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
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 Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/openchoreo/openchoreo | all versions | 1.0.2go get github.com/openchoreo/openchoreo@v1.0.2 |
| 🐹Go | github.com/openchoreo/openchoreo | ≥ 1.1.0&&< 1.1.2 | 1.1.2go get github.com/openchoreo/openchoreo@v1.1.2 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/openchoreo/openchoreo, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/openchoreo/openchoreo to 1.0.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-qh9r-j7rp-4x2m is resolved across your whole dependency graph.
Workarounds
Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.
Frequently Asked Questions
Is GHSA-qh9r-j7rp-4x2m in your dependencies?
Find it across Go, including transitive dependencies.