Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
6 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The OpenChoreo API server authorized PUT .../workflowruns/{runName} against ownership metadata taken from the request body, while the object it actually mutated was selected by the URL path. Nothing forced the two to agree. A WorkflowRun's membership in a project and component is carried entirely by its openchoreo.dev/project and openchoreo.dev/component labels. Because the workflowrun:update check read those labels from the submitted object rather than the stored one, a caller holding workflowrun:update on one component could name a run belonging to a different project or component in the URL, supply labels for the component they legitimately control, pass the check, and have the unrelated run rewritten with their own ownership labels. The namespace is taken from the URL and feeds both the authorization check and the Kubernetes read, so it cannot diverge. This is cross-project and cross-component escalation inside a single namespace, not a cross-tenant issue. Impact…
Recommended action: Upgrade to 1.2.5, 1.1.7 or 1.0.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OpenChoreo: cluster-gateway internal proxy performs no caller authentication and is not read-only — data-plane Secret disclosure and arbitrary Kubernetes mutation in github.com/openchoreo/openchoreo
Recommended action: Upgrade to 1.2.0, 1.1.3 or 1.0.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OpenChoreo Workflow Plane templates were vulnerable to OS command injection because some developer-controlled workflow parameters were interpolated directly into shell program text executed through sh -c. An authenticated user with permission to configure and trigger an affected workflow could supply crafted parameter values containing shell metacharacters. Because Argo substituted these values directly into the shell script before execution, the values could alter the script and execute arbitrary commands inside the workflow pod. In affected configurations, some build and publish templates used privileged Podman containers without Kubernetes pod user-namespace isolation. Consequently, injected commands could run as UID 0 inside a privileged container, with UID 0 mapped into the host user namespace. This substantially increased the potential impact of the command-injection vulnerability. The remediation ensures that workflow parameters are treated as data rather than…
Recommended action: Upgrade to 1.2.0-rc.2 (pre-release), 1.1.4 or 1.0.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The OpenChoreo autobuild webhook endpoint (POST /api/v1alpha1/autobuild) selected the git provider used to authenticate an incoming webhook from a client-supplied request header rather than from the target component's configuration, and its Bitbucket provider accepted requests without a valid signature. A caller could set the X-Event-Key header to be treated as a Bitbucket webhook, bypassing the HMAC secret that otherwise protects GitHub and GitLab webhooks, and trigger a component build without authenticating. Impact An attacker who can reach the autobuild webhook endpoint and knows the repository URL and branch configured for an auto-build component can trigger a build for that component without authenticating — including components configured for GitHub or GitLab, since the provider used or verification is chosen by the caller rather than by the component's configuration. The triggered build runs against a commit SHA supplied by the attacker, and the component lookup is…
Recommended action: Upgrade to 1.2.0-rc.2 (pre-release), 1.1.3 or 1.0.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/openchoreo/openchoreo >= 1.2.0-m.1, < 1.2.3; < 1.1.6
Fixed in
1.2.31.1.6· Vendor fix available
Issue
The OpenChoreo API server (openchoreo-api) authorized requests to its exec and wirelogs endpoints against the project supplied by the caller in the request, rather than against the project that actually owns the target component. The target component was resolved by name only, and the authorization engine decided purely from the caller-supplied resource hierarchy — the component's real owning project was never checked. As a result, an authenticated user who holds a project-scoped exec or log-viewing grant on any single project could run commands in, and read the wirelogs of, components owned by other projects in the same namespace. Impact An authenticated tenant holding a project-scoped component:exec grant on just one project can execute arbitrary commands — including an interactive shell — inside the running pods of components owned by any other project in the same namespace. This exposes those workloads' environment variables and mounted Secrets (such as database…
Recommended action: Upgrade to 1.2.3 or 1.1.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/openchoreo/openchoreo < 1.0.2; >= 1.1.0, < 1.1.2
Fixed in
1.1.21.0.2· Vendor fix available
Issue
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…
Recommended action: Upgrade to 1.1.2 or 1.0.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.