GHSA-3wf5-g532-rcrr: Argo Workflows: WorkflowTemplate Security Bypass via podSpecPatch in Strict/Secure Reference Mode
SummaryA user who can submit Workflows can completely bypass all security settings defined in a `WorkflowTemplate` by including a `podSpecPatch` field in their Workflow submission. This works even when the controller is configured with `templateReferencing: Strict`, which is specifically documented as a mechanism to restrict users to admin-approved templates. The `podSpecPatch` field on a submitted Workflow takes precedence over the referenced `WorkflowTemplate` during spec merging and is applied directly to the pod spec at creation time with no security validation.DetailsThree issues combine to create this vulnerability:Merge priority order:`JoinWorkflowSpec` merges specs with the priority order Workflow Spec > WorkflowTemplate Spec > WorkflowDefault Spec. Because `podSpecPatch` is a plain string field, the Workflow's value replaces the WorkflowTemplate's value.No security validation on `podSpecPatch`: `ApplyPodSpecPatch()` only validates that the patch is syntactically valid JSON conforming to the Kubernetes `PodSpec` schema. No checks are performed for dangerous security settings such as `privileged: true`.`templateReferencing: Strict` does not restrict `podSpecPatch`: Strict mode only checks whether `WorkflowTemplateRef` is set. If it is, the Workflow passes validation regardless of what other fields (including `podSpecPatch`) are present.PoCPrerequisitesA local Kubernetes cluster with Argo Workflows installed. The instructions below use [kind](https://kind.sigs.k8s.io/).1. Create a kind cluster and install Argo WorkflowsNote: `--server-side` is required because some CRDs exceed the client-side annotation size limit.Wait for the controller to be ready:2. Enable `templateReferencing: Strict`Patch the workflow controller configmap to enforce Strict mode:Restart the controller to pick up the new config:3. Verify Strict mode is activeAttempt to submit a standalone Workflow (no `workflowTemplateRef`). It should be rejected:The Workflow will be accepted by the API server but the controller will reject it. After a few seconds, check its status:Expected output:4: Create a hardened WorkflowTemplateAn administrator creates a `WorkflowTemplate` with restrictive security settings:5. Submit a legitimate Workflow (baseline)Submit a Workflow that references the secure template without modification:Wait for completion and check logs:Expected output (confirming the template's security settings are applied):6. Submit the bypass WorkflowSubmit a Workflow that references the same secure template but includes a `podSpecPatch` that overrides all security settings:Wait for completion and check logs:Expected output (all security settings bypassed):The file `/etc/shadow` is readable (root), the host filesystem is mounted and accessible, and the container runs as UID 0.ImpactThe purpose of `templateReferencing: Strict` is to restrict users to only execute admin-approved `WorkflowTemplates`. This is explicitly [documented](https://argo-workflows.readthedocs.io/en/latest/security/) as a security feature:You can typically further restrict what a user can do to just being able to submit workflows from templates using the workflow restrictions feature.A user who can submit Workflows referencing approved templates can use `podSpecPatch` to:Run containers as root (`runAsUser: 0`)Enable privileged mode (`privileged: true`)Mount the host filesystem (`hostPath` volumes)Share host PID/network/IPC namespaces (`hostPID`, `hostNetwork`, `hostIPC`)Add all Linux capabilities (`capabilities.add: ["ALL"]`)This effectively grants the user full root access to the underlying Kubernetes node, regardless of what security constraints the admin configured in the `WorkflowTemplate`.The `templateReferencing` feature was introduced in Argo Workflows v2.9.0 through PR #3149.MitigationWhen `templateReferencing: Strict` or `Secure` is enabled, the controller should reject Workflows that include a `podSpecPatch` field when using `workflowTemplateRef`.Without the codefix, deploying an admission controller (OPA/Gatekeeper, Kyverno) with policies that block dangerous pod settings (`privileged`, `hostPID`, `hostNetwork`, `hostIPC`, `hostPath`) on pods created by Argo Workflows.
CVSS v4.0: 8.9