OpenChoreo CVE-2026-73841

The attacker must be an authenticated OpenChoreo user holding at least a project-scoped grant (any project within the same Kubernetes namespace as the target) - CVSS PR:L confirms low-privilege authenticated access is required, not unauthenticated. The target system must be running OpenChoreo versions 1.2.0-rc.1 through pre-1.2.0 (release candidates only). The victim's components must reside in the same Kubernetes namespace as the attacker's project. The component:exec endpoint must be reachable for command injection, and/or the wirelogs:view endpoint must be reachable for log exfiltration. Limiting factors: (1) the attacker must already possess valid API credentials and a legitimate project grant - pure external unauthenticated access is blocked; (2) only release candidate deployments of 1.2.0 are affected, not prior stable versions; (3) cross-namespace exploitation is not possible - the authorization bypass operates within a single namespace boundary.

The CVSS 3.1 vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H scores 8.8, reflecting a network-reachable, low-complexity flaw requiring only low-privilege authentication (any project-scoped user). The triple High on C/I/A is justified: wirelogs may contain secrets or sensitive runtime data (Confidentiality), arbitrary command execution in another project's components corrupts workloads (Integrity), and exec access can terminate or crash container processes (Availability). There is no EPSS data available in the provided intelligence, and no CISA KEV listing confirms active exploitation - this reduces urgency somewhat but does not change the fundamental severity. The Scope remains Unchanged in the 3.1 assessment since the exploitation path stays within the OpenChoreo API control plane and its managed namespace, though the cross-project boundary crossing represents a meaningful trust violation. The low exploitation complexity (simply substituting a different project name in a query parameter) means weaponization effort is minimal, making this a high-priority remediation target for any multi-project OpenChoreo deployment despite the absence of confirmed in-the-wild exploitation. The narrow vulnerable version window (1.2.0-rc.1 through pre-1.2.0) limits exposure to deployments running release candidates.

An attacker who has legitimately obtained a project-scoped grant for their own project (project-attacker) within a shared OpenChoreo namespace issues an API request to the component:exec or wirelogs:view endpoint, substituting project-victim as the query parameter value. Because the authorization check trusts this caller-supplied value, the API grants access to a component owned by project-victim. The attacker can then execute arbitrary shell commands inside the victim project's containers or stream wirelogs containing potentially sensitive application secrets or output. No public exploit code has been identified, but the attack requires only constructing a well-formed HTTP request with a modified query parameter - a trivially low technical bar.