CVE-2025-66626

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.