Summary
An authorization flaw in OpenChoreo's WorkflowRun update route allows an authenticated user to modify another workflow run by combining a victim's URL identifier with ownership labels from a project or component they control. This may let the attacker gain access to run information, alter pending parameters, delete the run, or disrupt its execution within the same namespace.
An authorization flaw in OpenChoreo's WorkflowRun update route allows an authenticated user to modify another workflow run by combining a victim's URL identifier with ownership labels from a project or component they control. This may let the attacker gain access to run information, alter pending parameters, delete the run, or disrupt its execution within the same namespace.
Affected context
The issue occurs in OpenChoreo deployments where the WorkflowRun update endpoint identifies the stored object from the URL path but derives authorization from project and component labels supplied in the request body. It affects cross-project or cross-component access within a shared namespace when an authenticated caller has workflowrun:update permission for at least one controlled scope.
The issue occurs in OpenChoreo deployments where the WorkflowRun update endpoint identifies the stored object from the URL path but derives authorization from project and component labels supplied in the request body. It affects cross-project or cross-component access within a shared namespace when an authenticated caller has workflowrun:update permission for at least one controlled scope.
Exploit preconditions
- Attack surface: Authenticated HTTP PUT requests to the WorkflowRun update route
- Required access: Valid credentials with
workflowrun:updatepermission for a project or component in the target namespace - Trigger point: Updating a WorkflowRun identified by the URL path
- Why exploitation is possible: Authorization evaluates submitted ownership labels rather than confirming that those labels belong to the WorkflowRun selected by the path
- Scope limitation: The issue is not anonymous and does not provide cross-tenant access; the relevant runs must be reachable within the same namespace
- Attack surface: Authenticated HTTP PUT requests to the WorkflowRun update route
- Required access: Valid credentials with
workflowrun:updatepermission for a project or component in the target namespace - Trigger point: Updating a WorkflowRun identified by the URL path
- Why exploitation is possible: Authorization evaluates submitted ownership labels rather than confirming that those labels belong to the WorkflowRun selected by the path
- Scope limitation: The issue is not anonymous and does not provide cross-tenant access; the relevant runs must be reachable within the same namespace
Why this happens
The vulnerability is an insecure direct object reference combined with an authorization-object mismatch. The application selects a WorkflowRun using a caller-controlled path identifier but validates authorization against project and component labels supplied in the request body. Because the identity of the authorized scope is not consistently bound to the selected object, a caller authorized for one scope may influence another object's ownership metadata and gain permissions that should not apply. This behavior maps to CWE-639: Authorization Bypass Through User-Controlled Key.
The vulnerability is an insecure direct object reference combined with an authorization-object mismatch. The application selects a WorkflowRun using a caller-controlled path identifier but validates authorization against project and component labels supplied in the request body. Because the identity of the authorized scope is not consistently bound to the selected object, a caller authorized for one scope may influence another object's ownership metadata and gain permissions that should not apply. This behavior maps to CWE-639: Authorization Bypass Through User-Controlled Key.
Potential impact
- An attacker may rewrite ownership labels on another WorkflowRun
- An attacker could read build logs and Kubernetes events associated with the run
- An attacker may delete a victim WorkflowRun
- An attacker could modify pending workflow parameters
- A run may be forced into a permanent
ComponentValidationFailedstate - Workflow execution and development pipelines could be disrupted
- An attacker may rewrite ownership labels on another WorkflowRun
- An attacker could read build logs and Kubernetes events associated with the run
- An attacker may delete a victim WorkflowRun
- An attacker could modify pending workflow parameters
- A run may be forced into a permanent
ComponentValidationFailedstate - Workflow execution and development pipelines could be disrupted
General mitigation guidance
Mitigation should focus on binding authorization decisions to the object selected by the request path rather than to mutable ownership data supplied by the caller.
Common defensive patterns include:
- Resolve the target WorkflowRun and derive its authoritative project and component ownership from trusted server-side state
- Verify that the caller is authorized for the selected object before applying any update
- Prevent clients from changing ownership labels through ordinary update operations, or require a separate privileged workflow
- Apply immutable, server-controlled identifiers for authorization boundaries
- Enforce namespace and tenant isolation consistently at every object access path
- Use least-privilege permissions for workflow operations and audit sensitive updates
Mitigation should focus on binding authorization decisions to the object selected by the request path rather than to mutable ownership data supplied by the caller.
Common defensive patterns include:
- Resolve the target WorkflowRun and derive its authoritative project and component ownership from trusted server-side state
- Verify that the caller is authorized for the selected object before applying any update
- Prevent clients from changing ownership labels through ordinary update operations, or require a separate privileged workflow
- Apply immutable, server-controlled identifiers for authorization boundaries
- Enforce namespace and tenant isolation consistently at every object access path
- Use least-privilege permissions for workflow operations and audit sensitive updates
How teams detect issues like this
Organizations can look for this class of issue through:
- Static analysis and code review checks for authorization based on request-body ownership fields
- Review of handlers that use a URL identifier to select an object but validate permissions against different request data
- Tests that attempt same-namespace cross-project and cross-component object access
- Policy checks requiring server-side authorization after object resolution and before mutation
- Audit monitoring for unexpected changes to WorkflowRun ownership labels, deletion events, or parameter updates
- Automated security review tools that flag inconsistent object selection and authorization paths
Organizations can look for this class of issue through:
- Static analysis and code review checks for authorization based on request-body ownership fields
- Review of handlers that use a URL identifier to select an object but validate permissions against different request data
- Tests that attempt same-namespace cross-project and cross-component object access
- Policy checks requiring server-side authorization after object resolution and before mutation
- Audit monitoring for unexpected changes to WorkflowRun ownership labels, deletion events, or parameter updates
- Automated security review tools that flag inconsistent object selection and authorization paths
