CVE-2026-113727: OpenChoreo: Authorization bypass on WorkflowRun update allows cross-project takeover of workflow runs
OpenChoreo is a developer platform for Kubernetes. From 1.0.0 until 1.0.6, 1.1.7, and 1.2.5, the PUT .../workflowruns/{runName} update route authorizes a request using the openchoreo.dev/project and openchoreo.dev/component labels in the submitted body while selecting the stored WorkflowRun by the URL path. An authenticated caller with workflowrun:update for one project or component in the same namespace can name another run in the path, submit ownership labels for a scope they control, and rewrite the victim run's ownership labels. Subsequent authorization then treats the attacker as authorized to read build logs and Kubernetes events, delete the run, modify pending spec.workflow.parameters, or place the run into a permanent ComponentValidationFailed state. The namespace comes from the URL, so the issue is cross-project or cross-component within one namespace and is not anonymously reachable or cross-tenant. This issue is fixed in 1.0.6, 1.1.7, and 1.2.5.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
OpenChoreoto a version that resolves this vulnerability.Fixed in 1.0.6 - Upgrade
Upgrade
OpenChoreoto a version that resolves this vulnerability.Fixed in 1.1.7 - Upgrade
Upgrade
OpenChoreoto a version that resolves this vulnerability.Fixed in 1.2.5
Event History
Frequently Asked Questions
Who can exploit this issue?
An authenticated caller needs workflowrun:update permission for at least one project or component in the same namespace as the target WorkflowRun. The issue cannot be exploited anonymously and does not cross tenant or namespace boundaries.
What impact can an attacker have after taking over a WorkflowRun?
The attacker can rewrite the run's ownership labels, then gain authorization to read build logs and Kubernetes events, delete the run, change parameters in a pending spec.workflow, or permanently place it in the ComponentValidationFailed state.
Are default deployments affected?
Deployments are affected if they run a vulnerable OpenChoreo version and grant a user workflowrun:update permission for any project or component in a namespace containing other projects or components. Exploitation relies on shared namespace scope rather than anonymous access.
What should be done if patching cannot happen immediately?
Restrict workflowrun:update permissions so users cannot update WorkflowRuns in namespaces shared with projects or components they do not administer. Review and limit access for users who have update permission in shared namespaces.
How can I check for possible exploitation?
Review WorkflowRun updates for cases where the run named in the URL differs in ownership from the openchoreo.dev/project or openchoreo.dev/component labels submitted in the update body. Also investigate unexpected ownership-label changes, build-log or event access, deletions, parameter changes, and ComponentValidationFailed states for WorkflowRuns.