Description

OpenChoreo is a complete, open-source developer platform for Kubernetes. Prior to 1.0.3, 1.1.3, and 1.2.0-rc.2, internal/cluster-gateway/server.go exposed /api/proxy/, /api/exec/, and /api/wirelogs/ on an internal listener without requiring a client certificate or token, allowing any network-reachable caller to read tenant Kubernetes Secrets, mutate workloads, and execute commands across connected data planes. This issue is fixed in versions 1.0.3, 1.1.3, and 1.2.0-rc.2.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.0",
  "pubDate": "2026-08-13T22:17:29.037Z",
  "pubdate": "2026-08-13T22:17:29.037Z",
  "executiveSummary": "OpenChoreo, an open-source developer platform for Kubernetes, contains a critical authentication bypass vulnerability affecting its internal cluster gateway server. Specifically, internal/cluster-gateway/server.go exposes sensitive administrative endpoints including /api/proxy/, /api/exec/, and /api/wirelogs/ on an internal listener without enforcing mandatory cryptographic client certificate verification or bearer token validation. This security deficiency allows any network-reachable adversary or unauthenticated caller to bypass perimeter controls and directly interact with connected data planes. The business and operational implications of this vulnerability are severe, as successful exploitation grants unauthorized threat actors the capability to read sensitive tenant Kubernetes Secrets, mutate critical workloads, and execute arbitrary commands across the underlying cluster infrastructure. The risk profile is elevated due to the direct access to administrative execution and data retrieval primitives. Exploitation requirements are minimal from a network perspective, relying entirely on network reachability to the internal listener without requiring prior credentials, pre-existing privileges, or valid cryptographic identities. This vulnerability impacts OpenChoreo versions prior to 1.0.3, 1.1.3, and 1.2.0-rc.2, and has been officially resolved in those respective versions.",
  "technicalDetails": "The vulnerability resides within the internal cluster gateway implementation of OpenChoreo, specifically localized to internal/cluster-gateway/server.go. The root cause of the security flaw is the absence of mandatory authentication mechanisms on sensitive API routing paths exposed via an internal network listener. During the initialization and request handling lifecycle, the server fails to require or validate client certificates or security tokens for incoming requests directed at critical endpoints.\nThe vulnerable component exposes three high-privilege API routes: /api/proxy/, /api/exec/, and /api/wirelogs/. The /api/proxy/ endpoint allows request forwarding into connected cluster environments, /api/exec/ provides interactive command execution capabilities within containerized workloads, and /api/wirelogs/ potentially exposes sensitive operational logs and telemetry. Because the internal listener omits authentication enforcement, these powerful administrative primitives are exposed globally to any entity capable of routing packets to the listener port.\nThe attack flow proceeds as follows: First, an unauthenticated attacker establishes network connectivity to the internal listener exposed by OpenChoreo. Second, the attacker crafts an HTTP request targeting one of the unprotected sensitive paths, such as initiating an execution request against /api/exec/ or requesting tenant secrets via /api/proxy/. Third, because server.go does not validate client credentials or parse security tokens, the internal listener processes the request directly. Finally, the server forwards the request or executes the requested action against the connected data plane with the full privileges granted to the internal cluster gateway service account.\nPrivilege requirements for the attacker are non-existent; zero credentials or prior authorization are required to interact with the endpoints. Authentication requirements are entirely bypassed due to the missing access control checks in the routing logic. Network exposure encompasses any environment where the internal listener is reachable by untrusted networks or compromised internal network segments. Payload behavior involves submitting standard proxy routing parameters or execution arguments to coerce the gateway into performing privileged actions against Kubernetes clusters. The post-exploitation impact is catastrophic, enabling full read access to sensitive tenant Kubernetes Secrets, arbitrary workload mutation, and remote command execution across all connected data planes."
}