OpenChoreo EUVD-2026-105772

Requires a multi-tenant deployment pattern where more than one project or component shares a single Kubernetes namespace, and the attacker must be an authenticated caller already holding the workflowrun:update permission for at least one project or component in that namespace. The specific trigger is the PUT .../workflowruns/{runName} update route, which authorizes using the openchoreo.dev/project and openchoreo.dev/component labels supplied in the request body while selecting the stored WorkflowRun by the URL path; the attacker must also know (or enumerate) the name of a victim run in the same namespace. Limiting factors that reduce real-world risk: it is NOT anonymously reachable (valid credentials required), NOT cross-tenant (confined to one namespace per the URL-derived namespace), and a single-project-per-namespace deployment is not meaningfully exposed. Fixed by making the project/component ownership labels immutable on update and re-deriving authorization from the stored run.

This is a genuine but moderate-priority authorization flaw (CWE-639, IDOR/authorization bypass through a user-controlled key). The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:L, base 7.4) is internally consistent with the description: network-reachable, low complexity, but requiring an already-authenticated caller (PR:L) who holds workflowrun:update on at least one project or component in the target namespace. The scope change (S:C) is justified because the attacker crosses the project/component authorization boundary to affect resources they do not own. No EPSS score, no CISA KEV listing, and no public exploit code are provided in the input, so there is no signal of active or widespread exploitation - the risk is driven by the structural authorization defect, not by observed attacks. SSVC framing: exploitation status is 'none' (no POC/KEV), automatable is likely 'no' because it requires valid credentials and knowledge of a victim run name within the same namespace, and technical impact is 'partial' (consistent with the L/L/L impacts). The strongest mitigating factor is the explicit non-anonymous, non-cross-tenant boundary stated by the vendor: the attacker must already be an authenticated tenant with update rights inside the shared namespace. Net assessment: a legitimate internal/multi-project privilege-escalation issue worth patching promptly in multi-tenant OpenChoreo deployments, but not an emergency for single-project or single-team installations, and not a mass-exploitation candidate.

In a shared namespace hosting multiple projects, an authenticated developer who legitimately holds workflowrun:update on their own project sends a PUT to .../workflowruns/{victimRunName} with their own openchoreo.dev/project and openchoreo.dev/component labels in the body. The server authorizes against the attacker-supplied labels while loading the run named in the URL path, letting the attacker rewrite the victim run's ownership labels and subsequently read its build logs/events, delete it, alter pending workflow parameters, or force it into a permanent ComponentValidationFailed state. No public exploit is identified at time of analysis, and exploitation requires valid credentials plus knowledge of a victim run name in the same namespace.