CVE-2026-73667: Remote Code Execution via OS Command Injection in OpenChoreo Workflow Plane

The OpenChoreo Workflow Plane integrates with execution engines such as Argo Workflows to facilitate automated software delivery processes, including pulling source repositories, building container images, and deploying workloads within Kubernetes clusters. The platform distributes pre-configured workflow templates inside the OpenChoreo repository to provide boilerplate build-and-deploy pipelines for development teams. These default templates execute within highly privileged runner container configurations to support container-in-container workflows, such as running Podman or Docker commands inside the execution pods.\n\nBecause these automated tasks process diverse and dynamic user inputs during the build-and-deploy cycle, the templates constitute a critical attack surface. The core vulnerability, designated as CVE-2026-73667, is an OS command injection flaw located inside the default workflow templates. Specifically, the templates execute shell commands using dynamic inputs without proper validation or parameterization, creating an execution path for arbitrary system command insertion.\n\nAn authenticated user with permissions to trigger or configure workflow executions can supply crafted parameter values to exploit this vulnerability. Because the runner container executes by default as a privileged workload without host-user namespace mapping, successful exploitation leads to container breakout. This vulnerability affects OpenChoreo versions before 1.0.4, 1.1.x versions prior to 1.1.4, and 1.2.0 release candidates prior to 1.2.0-rc.2.

The vulnerability stems from two primary technical flaws within the template design, combined with a lack of proper container execution sandboxing. The first flaw is the reliance on server-side string interpolation. The Argo Workflows engine processes templates by searching for double-curly-brace placeholders, such as {{workflow.parameters.image-name}}, and replacing them textually before passing the generated command block to the container's shell interpreter via /bin/sh -c.\n\nThis textual search-and-replace mechanism acts as raw string concatenation inside code-execution blocks. If an attacker controls the value of the parameter, they can introduce command delimiters such as semicolons, ampersands, or newlines. When the shell parses the final command string, it treats these injected characters as syntax structures, executing the payload with the administrative privileges of the runner container.\n\nFurthermore, the second flaw lies in how the templates parse and evaluate JSON arrays. User-controlled variables are extracted dynamically using jq and concatenated into a flat shell variable without double quotes. When this variable is subsequently referenced in the build command, the Unix shell performs word-splitting and glob expansion, allowing an attacker to inject shell flags or command sequences even if the raw interpolation block is bypassed.\n\nThis combined execution environment is highly vulnerable due to the container configuration. By specifying privileged: true in the pod configuration without restricting host-user mapping, the container root user maps directly to UID 0 on the host system. Consequently, any shell access obtained within the container environment translates directly to root capabilities over the underlying host.

An inspection of the vulnerable template logic illustrates how user-controlled inputs were directly concatenated into executable shell paths. In the vulnerable configuration, variables such as IMAGE and APP_PATH are rendered directly into the shell script using bracket placeholders:\n\nyaml\nWORKDIR=/mnt/vol/source\nIMAGE="{{workflow.parameters.image-name}}:{{workflow.parameters.image-tag}}-{{inputs.parameters.git-revision}}"\nAPP_PATH="{{workflow.parameters.app-path}}"\nBUILD_ENV_JSON='{{workflow.parameters.build-env}}'\n\n\nWhen processed, if workflow.parameters.image-name is set to a malicious string, the resulting script block parsed by sh -c contains multiple logical command statements. Furthermore, the handling of the environment variable JSON array BUILD_ENV_JSON uses an unquoted shell variable to build command arguments:\n\nbash\nENV_ARGS=$(echo "$BUILD_ENV_JSON" | jq -r '.[] | "--env \(.name)=\(.value)"' | tr '\n' ' ')\n... \npodman build -t $IMAGE -f $WORKDIR/$DOCKERFILE_PATH $ENV_ARGS $WORKDIR\n\n\nThe variable $ENV_ARGS is expanded without double quotes, which triggers shell word-splitting on spaces and special shell characters. This allows the attacker to execute arbitrary secondary commands if they control the keys or values in BUILD_ENV_JSON.\n\nTo correct this vulnerability, the patched files decouple the template parsing from shell evaluation. The parameters are mapped to standard container environment variables instead of being injected as raw text into the script block. Inside the script, these variables are referenced securely using double-quoted shell expansion, which prevents token parsing of input strings:\n\nyaml\nenv:\n - name: IMAGE_NAME\n value: '{{workflow.parameters.image-name}}'\n...\nargs:\n - |\n IMAGE="${IMAGE_NAME}:${IMAGE_TAG}-${GIT_REVISION}"\n\n\nFor the JSON environment variable parser, the remediation utilizes positional parameters (set -- and "$@") to safely parse inputs. This ensures that arguments are treated as an argument vector (argv) rather than a single string, eliminating the risk of shell word-splitting.

Exploitation of CVE-2026-73667 requires authenticated network access with privileges sufficient to submit or modify workflow runs within the OpenChoreo environment. An attacker first identifies a target workflow utilizing the vulnerable templates, such as the containerfile-build.yaml template used during the standard image building phase. The attacker then structures a malicious workflow run request containing crafted parameters.\n\nTo exploit the raw string interpolation, the attacker provides a command separator in one of the evaluated fields, such as workflow.parameters.image-name. When the Argo workflow controller compiles the template, the bracket placeholders are replaced with the malicious payload. This raw output is then passed to the target container, where /bin/sh interprets the command separator and forks a background shell process to execute the injected payload.\n\nmermaid\ngraph LR\n A["Attacker Workflow Payload"] -->|"Injects command separator"| B["Argo Controller Text Interpolation"]\n B -->|"Assembles vulnerable shell script"| C["Privileged Runner Container"]\n C -->|"Executes sh -c"| D["Host Privilege Escalation via Host Namespace Mapping"]\n\n\nIf the attacker targets the environment variable reconstruction process, they can submit a crafted JSON array in BUILD_ENV_JSON. When jq extracts the elements, the unquoted shell variable expansion causes the shell to parse the keys and values as individual command-line options. By injecting spaces and metacharacters, the attacker triggers command execution during the execution of the builder binary. Because the container is configured with administrative privileges, the attacker can easily execute commands targeting the host namespace or the Docker socket.

The security impact of CVE-2026-73667 is rated high, with a CVSS v3.1 base score of 8.8. The primary risk associated with this vulnerability is the execution of arbitrary commands with root privileges inside a container configured with elevated cluster privileges. An attacker who successfully compromises the container can read and write arbitrary files inside the workspace volume, intercept build-time secrets, and compromise subsequent software deployment pipelines.\n\nDue to the lack of user namespace isolation within the default configuration of these workflow templates, the root user inside the runner container maps directly to the host's root user. A compromised runner container can easily access the underlying node's filesystem, mount host drives, and communicate with container runtimes. Consequently, container breakout and full worker node compromise are highly feasible outcomes.\n\nmermaid\ngraph LR\n Sub1["Runner Container Namespace"] -->|"hostUsers: true / Privileged"| Sub2["Kubernetes Host Node Namespace"]\n Sub1 -->|"Access container runtime socket"| Sub2\n Sub1 -->|"Mount host root filesystem"| Sub2\n\n\nWhile the Exploit Prediction Scoring System (EPSS) rating for this vulnerability remains low, the technical ease of exploitation makes it a prime target for automated or lateral cluster attacks. Any authenticated attacker with permissions to run workflows can use this flaw to escalate privileges from a standard application space to complete node administration.

The primary remediation path is to upgrade OpenChoreo deployments to the patched versions: 1.0.4, 1.1.4, or 1.2.0-rc.2. These releases update the packaged workflow templates to eliminate all instances of server-side bracket interpolation inside inline shell scripts. Additionally, the updated templates implement safe positional argument parsing and enforce user namespace isolation to prevent host privilege escalation.\n\nFor environments where immediate patching of the platform is not viable, administrators must manually review and remediate active workflow templates. Ensure that all instances of Argo bracket expressions inside shell commands are migrated to container environment variables. In the shell scripts, these variables must be enclosed within double quotes to prevent the command interpreter from executing metacharacters.\n\nyaml\n# Correct configuration pattern\nenv:\n - name: APP_PATH\n value: '{{workflow.parameters.app-path}}'\n\n\nFurthermore, organizations must ensure that Kubernetes workloads enforce the host-user namespace constraint hostUsers: false inside the workflow execution pod templates. Applying this configuration restricts container-level root privileges to isolated namespaces, minimizing the impact of potential breakouts. Organizations can enforce this setting cluster-wide by deploying admission policies.