Summary
Argo Workflows contains a privilege management flaw where user-controlled fields in WorkflowSpec.ArtifactGC.PodSpecPatch are not fully validated or sanitized before being applied to the artifact-GC pod.
Under Strict or Secure template reference modes, a user can still inject arbitrary pod-level configuration, enabling hostPath mounts, privileged containers, custom images, and host networking, undermining the intended security guarantees.
Argo Workflows contains a privilege management flaw where user-controlled fields in WorkflowSpec.ArtifactGC.PodSpecPatch are not fully validated or sanitized before being applied to the artifact-GC pod.
Under Strict or Secure template reference modes, a user can still inject arbitrary pod-level configuration, enabling hostPath mounts, privileged containers, custom images, and host networking, undermining the intended security guarantees.
Affected context
This vulnerability appears in Argo Workflows deployments that:
- Use Strict or Secure
templateReferencingmodes to limit what workflow submitters can customize - Rely on referenced
WorkflowTemplateobjects that define output artifacts - Enable artifact garbage collection with
spec.artifactGC.strategy: OnWorkflowCompletion
In this context, the artifact-GC pod is spawned with configuration derived from WorkflowSpec.ArtifactGC, and its nested PodSpecPatch field can carry unvalidated user-supplied changes into the pod spec.
This vulnerability appears in Argo Workflows deployments that:
- Use Strict or Secure
templateReferencingmodes to limit what workflow submitters can customize - Rely on referenced
WorkflowTemplateobjects that define output artifacts - Enable artifact garbage collection with
spec.artifactGC.strategy: OnWorkflowCompletion
In this context, the artifact-GC pod is spawned with configuration derived from WorkflowSpec.ArtifactGC, and its nested PodSpecPatch field can carry unvalidated user-supplied changes into the pod spec.
Exploit preconditions
- Attack surface: Argo Workflows API or UI used to submit
Workflowobjects - Required access: Ability to create or modify workflows that reference existing
WorkflowTemplateresources configured with output artifacts - Trigger point: Submission of a workflow under Strict or Secure template reference modes with crafted
spec.artifactGC.PodSpecPatch - Why exploitation is possible: The validation and sanitization routines walk only top-level
WorkflowSpecfields and treatArtifactGCas fully allow-listed. The nestedWorkflowLevelArtifactGC.PodSpecPatchis passed unmodified intoutil.ApplyPodSpecPatch, enabling arbitrary strategic merge patches against the artifact-GC pod spec.
- Attack surface: Argo Workflows API or UI used to submit
Workflowobjects - Required access: Ability to create or modify workflows that reference existing
WorkflowTemplateresources configured with output artifacts - Trigger point: Submission of a workflow under Strict or Secure template reference modes with crafted
spec.artifactGC.PodSpecPatch - Why exploitation is possible: The validation and sanitization routines walk only top-level
WorkflowSpecfields and treatArtifactGCas fully allow-listed. The nestedWorkflowLevelArtifactGC.PodSpecPatchis passed unmodified intoutil.ApplyPodSpecPatch, enabling arbitrary strategic merge patches against the artifact-GC pod spec.
Why this happens
The underlying bug is an incomplete authorization and validation model for user-controlled configuration fields within workflow specifications.
Argo's security design intends Strict/Secure template reference modes to constrain what users can change in the resulting pod spec. However, the implementation in ValidateUserOverrides and SanitizeUserWorkflowSpec only inspects top-level WorkflowSpec fields by reflection and broadly allow-lists ArtifactGC.
As a result, the nested WorkflowLevelArtifactGC.PodSpecPatch is not subjected to the same restrictions as WorkflowSpec.PodSpecPatch. This inconsistent enforcement of policy maps to CWE-284: Improper Access Control, because it allows users to bypass privilege boundaries and apply unauthorized changes to pod-level configuration.
The underlying bug is an incomplete authorization and validation model for user-controlled configuration fields within workflow specifications.
Argo's security design intends Strict/Secure template reference modes to constrain what users can change in the resulting pod spec. However, the implementation in ValidateUserOverrides and SanitizeUserWorkflowSpec only inspects top-level WorkflowSpec fields by reflection and broadly allow-lists ArtifactGC.
As a result, the nested WorkflowLevelArtifactGC.PodSpecPatch is not subjected to the same restrictions as WorkflowSpec.PodSpecPatch. This inconsistent enforcement of policy maps to CWE-284: Improper Access Control, because it allows users to bypass privilege boundaries and apply unauthorized changes to pod-level configuration.
Potential impact
- Users may escalate privileges by creating pods with
privileged: truecontainers. - Attackers could mount sensitive hostPath volumes, gaining direct access to node filesystem data.
- Workflows can run arbitrary images and commands outside the intended template constraints.
- Host networking (
hostNetwork: true) may be enabled, increasing exposure and facilitating network-level attacks. - The Strict/Secure template reference mode can be effectively neutralized, undermining multi-tenant isolation and cluster security assumptions.
- Users may escalate privileges by creating pods with
privileged: truecontainers. - Attackers could mount sensitive hostPath volumes, gaining direct access to node filesystem data.
- Workflows can run arbitrary images and commands outside the intended template constraints.
- Host networking (
hostNetwork: true) may be enabled, increasing exposure and facilitating network-level attacks. - The Strict/Secure template reference mode can be effectively neutralized, undermining multi-tenant isolation and cluster security assumptions.
General mitigation guidance
Effective mitigation centers on enforcing consistent, fine-grained controls over all user-influenced fields that affect pod specifications.
Recommended patterns include:
- Treat nested configuration structures (such as artifact GC settings and any
PodSpecPatch-like fields) as untrusted input and subject them to the same allow-list or deny-list logic as top-level pod customization fields. - Implement schema-based validation that explicitly enumerates which pod spec attributes users may modify, rather than broadly allow-listing composite structs.
- Separate user-controllable workflow metadata from pod-level security-sensitive options, ensuring that high-risk fields (privileged, hostPath, hostNetwork, capabilities, volumes, and securityContext) are owned by administrators or templates only.
- Apply least-privilege defaults to pods spawned for auxiliary tasks such as artifact garbage collection, minimizing their access to host resources and cluster-wide permissions.
- Consider centralizing policy enforcement (e.g., admission-like validations) so that any route that ultimately generates a pod spec must pass through a uniform security filter.
Effective mitigation centers on enforcing consistent, fine-grained controls over all user-influenced fields that affect pod specifications.
Recommended patterns include:
- Treat nested configuration structures (such as artifact GC settings and any
PodSpecPatch-like fields) as untrusted input and subject them to the same allow-list or deny-list logic as top-level pod customization fields. - Implement schema-based validation that explicitly enumerates which pod spec attributes users may modify, rather than broadly allow-listing composite structs.
- Separate user-controllable workflow metadata from pod-level security-sensitive options, ensuring that high-risk fields (privileged, hostPath, hostNetwork, capabilities, volumes, and securityContext) are owned by administrators or templates only.
- Apply least-privilege defaults to pods spawned for auxiliary tasks such as artifact garbage collection, minimizing their access to host resources and cluster-wide permissions.
- Consider centralizing policy enforcement (e.g., admission-like validations) so that any route that ultimately generates a pod spec must pass through a uniform security filter.
How teams detect issues like this
Organizations can identify and monitor this class of misconfiguration and access control issues using:
- Static analysis and configuration linting that flag any user-facing fields which ultimately feed into pod spec generation without passing through policy checks or sanitization.
- Code review practices focused on paths like
ApplyPodSpecPatchand similar functions that merge user-supplied patches into pod specifications, verifying that all call sites are gated by the same enforcement logic. - Cluster-level security policies (e.g., admission controllers, policy engines) that detect and optionally block pods created by Argo with disallowed attributes such as hostPath volumes, privileged containers, or host networking, regardless of how those configurations originated.
- Automated pipeline checks that inspect Argo-related manifests and workflow definitions for unexpected
PodSpecPatchusage and high-risk fields, providing early warning before deployment.
Organizations can identify and monitor this class of misconfiguration and access control issues using:
- Static analysis and configuration linting that flag any user-facing fields which ultimately feed into pod spec generation without passing through policy checks or sanitization.
- Code review practices focused on paths like
ApplyPodSpecPatchand similar functions that merge user-supplied patches into pod specifications, verifying that all call sites are gated by the same enforcement logic. - Cluster-level security policies (e.g., admission controllers, policy engines) that detect and optionally block pods created by Argo with disallowed attributes such as hostPath volumes, privileged containers, or host networking, regardless of how those configurations originated.
- Automated pipeline checks that inspect Argo-related manifests and workflow definitions for unexpected
PodSpecPatchusage and high-risk fields, providing early warning before deployment.
