Advisories for Golang/Github.com/Argoproj/Argo-Workflows/V4 package

2026

Argo has incomplete fix for CVE-2026-31892: hostNetwork, securityContext, serviceAccountName bypass templateReferencing Strict/Secure

The fix for CVE-2026-31892 (commit 534f4ff) blocks podSpecPatch when templateReferencing: Strict is active, but doesn't restrict other WorkflowSpec fields that flow through the same merge path and get applied to pods. A user can set hostNetwork: true, override serviceAccountName, or change securityContext on their Workflow while referencing a hardened template – these survive JoinWorkflowSpec and get applied at pod creation. The check in setExecWorkflow gates on HasPodSpecPatch() only: if woc.controller.Config.WorkflowRestrictions.MustUseReference() …

Argo Workflows: Unchecked annotation parsing in pod informer crashes Argo Workflows Controller

An unchecked array index in the pod informer's podGCFromPod() function causes a controller-wide panic when a workflow pod carries a malformed workflows.argoproj.io/pod-gc-strategy annotation. Because the panic occurs inside an informer goroutine (outside the controller's recover() scope), it crashes the entire controller process. The poisoned pod persists across restarts, causing a crash loop that halts all workflow processing until the pod is manually deleted.

Argo Workflows: WorkflowTemplate Security Bypass via podSpecPatch in Strict/Secure Reference Mode

A 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 …