OpenChoreo API server authorization flaw allows cross-component workflow escalation
A high-severity authorization bypass in OpenChoreo lets attackers rewrite workflow run labels to steal access to unrelated build logs and credentials.
Key points
- CVE-2026-113727 affects OpenChoreo versions prior to 1.0.6, 1.1.7, and 1.2.5.
- Attackers can escalate privileges by mismatching URL paths and request body labels.
- Exploitation requires an authenticated user with existing workflow update permissions.
The OpenChoreo API server contains a high-severity authorization bypass, tracked as CVE-2026-113727, that allows authenticated users to escalate privileges across different projects and components within the same namespace. The flaw stems from how the server validates ownership during workflow run updates. Instead of verifying that the resource identified in the URL matches the ownership metadata in the request body, the server accepts mismatched data. This discrepancy enables a caller to target a resource they do not own while presenting ownership details for a resource they do control.
Root cause
The vulnerability arises because the `workflowrun:update` authorization check reads project and component labels from the submitted request object rather than the stored database record. A `WorkflowRun`’s membership is defined by `openchoreo.dev/project` and `openchoreo.dev/component` labels. The server uses the URL path to select the object to mutate but relies on the body for authorization decisions. Nothing in the logic forces these two sources to agree. Consequently, an attacker can specify a target run in the URL path while supplying legitimate ownership labels in the body, causing the authorization check to pass incorrectly.
Attack path
An attacker must possess an `AuthzRoleBinding` with `workflowrun:update` permissions on at least one component. They construct a `PUT` request to the `.../workflowruns/{runName}` endpoint, specifying a target run belonging to a different project or component in the URL. In the request body, they include labels corresponding to the component they legitimately control. The server validates the body labels, grants access, and then applies those labels to the URL-specified run. This rewrite transfers authority over the victim’s run to the attacker.
Affected versions
The following OpenChoreo version ranges are vulnerable to this authorization bypass:
- Versions 1.0.0 through 1.0.5 (patched in 1.0.6)
- Versions 1.1.0 through 1.1.6 (patched in 1.1.7)
- Versions 1.2.0 through 1.2.4 (patched in 1.2.5)
Mitigation
- Upgrade OpenChoreo to version 1.0.6, 1.1.7, or 1.2.5 depending on your current major release line.
- Audit `AuthzRoleBinding` configurations to ensure users only have `workflowrun:update` permissions where strictly necessary.
- Monitor workflow run logs for unexpected ownership label changes or access from unauthorized components.
Signals worth monitoring
Security teams should investigate any workflow run label modifications that do not align with the original component owner. Check audit logs for `PUT` requests to workflow endpoints where the URL path and request body metadata diverge. Look for sudden access patterns where a user reads build logs or events for components they previously could not access. Verify that namespace boundaries are respected, as this flaw operates within a single namespace. Alert on any workflow runs stuck in validation failures or those that skip component checks unexpectedly.
What to do and how to stay safe: OpenChoreo
- Inventory all OpenChoreo instances and compare installed versions against the patched releases listed above.
- Review access logs for the past thirty days to identify any unauthorized workflow run modifications or label rewrites.
- Restrict `workflowrun:update` permissions to only those users who require them for their specific component management tasks.
- Once the vendor provides an update, deploy the patch immediately and verify that authorization checks now validate stored object labels.
Step-by-step guide: Attack Surface Management: 6 Common Misreadings and Correct Views
General security guidance from the NetSec Observer newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
Does this vulnerability allow access across different namespaces?
No, the namespace is derived from the URL and feeds both the authorization check and the Kubernetes read, preventing cross-tenant or cross-namespace exploitation.
What is the primary impact of exploiting this flaw?
The primary impact is confidentiality and availability, as attackers can read build logs containing credentials and delete workflow runs, in addition to integrity issues.
Can an attacker modify the workflow parameters?
Yes, on a pending run, an attacker can overwrite `spec.workflow.parameters` and manipulate ownership labels to wedge the run in a failed state or skip validation.
