CVE-2026-113727 in OpenChoreo
Summary
by MITRE • 10/21/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/21/2026
The vulnerability identified in OpenChoreo versions ranging from 1.0.0 to 1.0.5, as well as specific releases of the 1.1.x and 1.2.x branches up to 1.1.7 and 1.2.5, represents a critical Insecure Direct Object Reference (IDOR) flaw within the workflow execution management subsystem. OpenChoreo serves as a developer platform for Kubernetes, facilitating the orchestration of complex workflows across containerized environments. The core technical deficiency lies in how the PUT endpoint responsible for updating workflow runs validates authorization claims against the target resource. Specifically, when an authenticated user submits a request to update a specific workflow run identified by its name in the URL path, the system incorrectly relies on ownership labels present within the submitted request body rather than verifying that these labels correspond to the actual stored metadata of the targeted WorkflowRun object. This architectural misalignment allows an attacker who possesses write permissions for one project or component within a Kubernetes namespace to manipulate the state of workflow runs belonging to other projects or components in that same namespace, provided they can control the label values submitted in their request payload.
From a technical perspective, this flaw exploits the separation between resource identification and authorization validation. The URL path explicitly identifies the target WorkflowRun object by its unique name within the Kubernetes API server context. However, the backend logic authorizes the operation based on openchoreo.dev/project and openchoreo.dev/component labels found in the request body submitted by the client. Since these labels are user-controllable inputs rather than immutable attributes of the resource itself, an attacker can craft a malicious payload containing ownership labels associated with their own authorized scope while targeting a victim's workflow run via the URL path. Upon receiving this request, the system accepts the provided labels as proof of authorization and proceeds to update the target WorkflowRun object. This effectively bypasses access controls intended to isolate resources between different projects or components within the same namespace, creating a cross-project privilege escalation vector that is not limited by tenant boundaries but remains confined to single-namespace scopes due to Kubernetes RBAC constraints.
The operational impact of this vulnerability is severe and multifaceted, affecting both data confidentiality and system integrity. Once an attacker successfully rewrites the ownership labels of a victim's workflow run, subsequent authorization checks treat the attacker as the legitimate owner or authorized manager of that run. This grants the attacker elevated privileges to perform actions that should be restricted to the original project owners. These malicious capabilities include reading sensitive build logs which may contain proprietary source code, API keys, or internal network configurations; accessing Kubernetes events associated with the workflow execution environment; deleting critical workflow runs thereby disrupting business processes and causing denial of service for legitimate users; modifying pending spec.workflow.parameters to alter runtime behavior potentially leading to arbitrary command execution or data exfiltration if parameters are passed directly to shell commands or external services; and forcing the run into a permanent ComponentValidationFailed state, which can be used as an availability attack vector. The ability to modify workflow parameters is particularly dangerous in CI/CD pipelines where such modifications could trigger destructive deployment actions or inject malicious code into build artifacts.
This vulnerability aligns with CWE-639, Authorization Bypass Through User-Controlled Key, and falls under the MITRE ATT&CK technique T1078, Valid Accounts, specifically illustrating how valid credentials can be leveraged to escalate privileges through flawed logic rather than credential theft. It also relates to CWE-284, Improper Access Control, as the system fails to enforce proper restrictions on authorized users accessing resources belonging to other entities within their scope of access. The issue is not anonymously reachable and does not allow cross-tenant attacks due to Kubernetes namespace isolation mechanisms, but it poses a significant risk in multi-project development environments where teams share namespaces for resource efficiency or collaborative purposes. Organizations running affected versions must immediately upgrade to patched releases 1.0.6, 1.1.7, or 1.2.5 and later which correct the authorization logic by validating ownership labels against the actual stored attributes of the target WorkflowRun object rather than trusting client-supplied values. Additionally, implementing strict input validation on all label fields in API requests and adopting a principle of least privilege for service accounts interacting with workflow run resources can further mitigate similar risks in future developments.