Argo Workflows vulnerabilities

A vulnerability in Argo Workflows before versions 3.7.15 and 4.0.6 allows bypassing the allow-list fix for CVE-2026-31892. Through the ArtifactGC field in WorkflowSpec, a user can inject an arbitrary strategic merge patch into the artifact-GC pod, including dangerous settings like hostPath, privileged mode, or hostNetwork.

Argo Workflows prior to versions 4.0.2 and 3.7.11 contains a vulnerability that allows unauthorized clients to retrieve WorkflowTemplates and ClusterWorkflowTemplates by sending a request with any token in the Authorization header. This can lead to disclosure of sensitive data, including embedded Secret manifests.

Argo Workflows versions 4.1.0 through 4.1.3 contain an authorization bypass vulnerability in ListArchivedWorkflows that fails to apply cluster-scoped access review when the metadata.namespace field selector uses the NotEquals operator. Attackers with namespace-scoped list permissions can use a negated namespace field selector to retrieve archived workflows from all other namespaces, exposing spec arguments, parameter values, and annotations.

Argo Workflows versions 4.0.0 to before 4.0.5 have a vulnerability in the Sync Service where the ConfigMap-backed provider performs zero authorization checks on CRUD operations. Any authenticated user, including those using fake Bearer tokens, can create, read, update, and delete Kubernetes ConfigMaps containing synchronization limits.

Argo Workflows before versions 3.7.14 and 4.0.5 allows a user with create Workflow permission to bypass Strict templateReferencing mode. This enables host network access, service account switching, pod security context override, tolerations for control-plane nodes, or SA token mounting.

Argo Workflows from version 4.0.0 to before 4.0.5 logs all artifact repository credentials (S3 access keys, secret keys, GCS service account keys, Azure account keys, Git passwords, etc.) in plaintext during artifact operations. Any user with read access to workflow pod logs can extract these credentials. This is fixed in version 4.0.5.

Argo Workflows before versions 3.7.14 and 4.0.5 loads the entire request body into memory before authentication or signature verification on the publicly accessible /api/v1/events/ endpoint. An attacker can send a very large request, causing excessive memory usage and an OOM crash.

Argo Workflows versions 4.0.0 to 4.0.5 have a nil pointer dereference in rbacAuthorization() in server/auth/gatekeeper.go, causing a panic (denial of service) for SSO users whose claims match a namespace-level RBAC rule but not an SSO-namespace rule when SSO_DELEGATE_RBAC_TO_NAMESPACE=true.

A vulnerability in Argo Workflows from version 3.6.5 to 4.0.4 causes a controller panic due to an unchecked array index in the pod informer's podGCFromPod() function. A malicious workflows.argoproj.io/pod-gc-strategy annotation on a workflow pod crashes the entire controller process, and after restart, it creates a crash loop that halts all workflow processing.

A vulnerability in Argo Workflows allows a user with Workflow submission privileges to completely bypass all security settings defined in a WorkflowTemplate. By including a podSpecPatch field in their submitted Workflow, the user can override template settings even when the controller is configured with templateReferencing: Strict.

Stored XSS vulnerability in Argo Workflows allows arbitrary JavaScript execution in another user's browser via artifact directory listing. Affects versions prior to 3.6.17 and 3.7.8.

Argo Workflows versions prior to 3.6.12 and 3.7.0 through 3.7.2 expose artifact repository credentials in plaintext in workflow-controller pod logs. An attacker with permissions to read pod logs in a namespace can read the logs and obtain credentials.

Argo Workflows versions prior to 3.6.12 and versions 3.7.0 through 3.7.2 contain a Zip Slip path traversal vulnerability in artifact extraction. During artifact extraction the unpack/untar logic uses filepath.Join(dest, filepath.Clean(header.Name)) without validating that header.Name stays within the intended extraction directory. A malicious archive entry can supply a traversal or absolute path that, after cleaning, overrides the destination directory and causes files to be written outside the /work/tmp extraction path and into system directories such as /etc inside the container. The vulnerability enables arbitrary file creation or overwrite in system configuration locations (for example /etc/passwd, /etc/hosts, /etc/crontab), which can lead to privilege escalation or persistence within the affected container. Update to 3.6.12 or 3.7.3 to remediate the issue.