Attack Chain

1. Attacker gains access to a low-privileged account with a valid component:exec or wirelogs:view grant for a single project within an OpenChoreo-managed namespace.
2. Attacker identifies a high-value target component in a different project within the same namespace.
3. Attacker crafts an HTTP request to the openchoreo-api exec or wirelogs endpoint.
4. Attacker substitutes the project parameter in the request with the identifier of the victim's component project.
5. The API server processes the request, resolving the target component by name without verifying the ownership relationship.
6. The authorization engine validates the attacker's grant against the caller-supplied (spoofed) project ID.
7. The server grants the attacker access, permitting command execution or log retrieval from the target component pod.

Impact

The vulnerability allows unauthorized users to achieve remote command execution or sensitive data exfiltration from workloads they do not own, provided the target is within the same namespace. Successful exploitation allows for the compromise of environment variables and Kubernetes Secrets associated with the targeted component, lateral movement within the cluster, and potential disruption of service integrity across different organizational teams sharing a namespace.

Recommendation

Prioritized actions for security and infrastructure teams:

• Upgrade openchoreo-api to version 1.2.3 or 1.1.6 immediately to enforce correct project-based authorization (CVE-2026-73841).
• Audit existing component:exec and wirelogs:view grants to ensure they are restricted to trusted operators only.
• Segregate highly sensitive components into distinct Kubernetes namespaces to prevent cross-project access while the patch is being deployed.
• Review cluster-gateway configuration to ensure internal proxies enforce caller authorization, addressing the related security gaps noted in GHSA-rh53-xvx2-j327.

The vulnerability is particularly critical because certain build and publish templates run Podman containers in a privileged mode without Kubernetes pod user-namespace isolation enabled. In these configurations, an attacker successfully performing command injection gains UID 0 within a privileged container. Because the container lacks user namespace isolation, this UID 0 is mapped directly to UID 0 on the host, granting the attacker significant capabilities and potentially facilitating a container escape or node-level compromise. The issue was addressed by moving away from direct shell interpolation to the use of container environment variables and argument vectors.

Attack Chain

1. Attacker gains authentication access to the OpenChoreo environment with permissions to configure or trigger workflow templates.
2. Attacker identifies a workflow template that accepts user-supplied parameters interpolated into a shell script executed by the workflow engine.
3. Attacker submits a workflow request containing malicious shell metacharacters (e.g., ; , &&, |) within a vulnerable input parameter.
4. The OpenChoreo Workflow Plane processes the template and directly interpolates the malicious parameter into a shell command string.
5. The workflow pod executes the resulting malicious string via 'sh -c', triggering the attacker-supplied commands within the pod context.
6. The injected commands execute with the privileges assigned to the container (e.g., root/UID 0).
7. If the container is running in privileged mode without user namespace isolation (hostUsers: false), the attacker attempts to interact with host-level resources or devices to escalate privileges or escape the container.
8. Final objectives may include credential exfiltration (Git/registry/service account tokens), source code theft, or persistent access to the Kubernetes node.

Impact

Successful exploitation allows an authenticated attacker to gain unauthorized code execution within the context of a workflow pod. Depending on the environment and template configuration, this leads to the potential exposure of sensitive data, including Git and registry credentials, Kubernetes service account tokens, and source code. Because privileged containers without user namespace isolation map the container's root user to the host's root user, the impact can extend to a full compromise of the underlying Kubernetes node if the attacker manages to exploit kernel or node-level vulnerabilities from within the privileged container context.

Recommendation

1. Upgrade OpenChoreo immediately to version 1.0.4, 1.1.4, or 1.2.0-rc.2.
2. For clusters running custom workflow templates, manually review and update templates to remove direct shell interpolation, replacing them with quoted shell variables passed through container environment variables or separate argument-vector entries.
3. Ensure that all containers utilizing privileged Podman execution have hostUsers: false explicitly set in their security context to enable user namespace isolation and prevent root-to-root mapping on the host.
4. Enforce strict RBAC policies to restrict the ability to create, modify, or trigger workflows to a highly limited set of trusted users.
5. Audit existing workflow templates for any instances of shell metacharacter usage in user-defined parameters to identify potential historical exploitation attempts.

Attack Chain

1. Attacker performs network reconnaissance to identify exposed OpenChoreo cluster-gateway endpoints.
2. Attacker confirms the target is a multi-cluster deployment with an externally published listener.
3. Attacker sends unauthenticated HTTP requests to the identified management API paths on the gateway listener.
4. Attacker invokes privileged API operations intended for the OpenChoreo control-plane.
5. Attacker proxies requests to the underlying data-plane Kubernetes API.
6. Attacker leverages the proxied API access to target specific workload pods.
7. Attacker executes arbitrary commands or manipulates workloads, leading to full compromise.

Impact

Successful exploitation leads to a complete compromise of the data-plane workloads. This includes unauthorized data disclosure, unauthorized modification of services, and potential denial of service. The impact is significant for organizations relying on OpenChoreo for multi-cluster management, as the vulnerability bypasses existing control-plane authorization, granting an unauthenticated attacker the same privileges as an authenticated internal client.

Recommendation

Prioritized actions for addressing CVE-2026-73843:

• Upgrade OpenChoreo cluster-gateway to versions 1.0.2, 1.1.2, or 1.2.0 immediately to move management APIs to a secure internal listener.
• For deployments that cannot be patched immediately, apply firewall or network policy rules to restrict the externally published gateway endpoint to only allow traffic from authorized data-plane source addresses.
• Review ingress and network telemetry to identify unauthorized access attempts to the management API paths on the cluster-gateway listener.