OpenChoreo vulnerabilities
6 known CVE vulnerabilities in OpenChoreo, translated and rated.
- CVE-2026-73843Critical
OpenChoreo prior to 1.0.2 and 1.1.2 served caller-facing management APIs on the externally reachable agent listener without authentication, allowing network-reachable attackers to invoke /api/proxy/ and /api/exec/ operations, proxy the data-plane Kubernetes API, and execute commands in workload pods in multi-cluster deployments.
- CVE-2026-73842Critical
OpenChoreo prior to 1.0.3, 1.1.3, and 1.2.0-rc.2 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.
- CVE-2026-73841High
OpenChoreo up to version 1.2.0 has a vulnerability where authorization for commands and wirelogs uses the caller-supplied project parameter instead of the actual component owner. A user with project-scoped grants can execute commands and read wirelogs in components of other projects in the same namespace.
- CVE-2026-73840Medium
OpenChoreo prior to versions 1.0.3, 1.1.3, and 1.2.0-rc.2 has a vulnerability in the POST /api/v1alpha1/autobuild endpoint. Webhook provider selection relies on attacker-controlled X-Event-Key, and Bitbucket requests are accepted without HMAC-SHA256 verification. This allows unauthenticated build triggers for components matched by repository URL and branch, including cross-provider attacks using attacker-supplied commit SHAs.
- CVE-2026-73667High
OpenChoreo before versions 1.0.4, 1.1.4, and 1.2.0-rc.2 has a vulnerability in Workflow Plane templates where developer-controlled parameters are interpolated into shell code executed via sh -c instead of being passed through container.env. This allows arbitrary commands to run in workflow pods, and affected privileged Podman templates lacked hostUsers: false.
- CVE-2026-73666High
OpenChoreo before versions 1.0.4, 1.1.4, and 1.2.1 has a vulnerability in the Backstage backend where default authentication policy is hardcoded to be disabled and guest access is allowed outside development. This results in unauthenticated access to /api/*, allowing unauthenticated catalog reads, scaffolder log reads, and catalog location creation or deletion.

