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

Severity: Medium Component: Webhook Interceptor (server/auth/webhook) Vulnerability Type: Denial of Service (DoS)

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() …

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.

Workflow templates endpoints allow any client to retrieve WorkflowTemplates (and ClusterWorkflowTemplates). Any request with a Authorization: Bearer nothing token can leak sensitive template content, including embedded Secret manifests.

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 …

Stored XSS in the artifact directory listing allows any workflow author to execute arbitrary JavaScript in another user’s browser under the Argo Server origin, enabling API actions with the victim’s privileges.

The patch deployed against CVE-2025-62156 is ineffective against malicious archives containing symbolic links.

An attacker who has permissions to read logs from pods in a namespace with Argo Workflow can read workflow-controller logs and get credentials to the artifact repository.

Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. 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 (workflow/executor/executor.go) 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 …

When using –auth-mode=client, Archived Workflows can be retrieved with a fake or spoofed token via the GET Workflow endpoint: /api/v1/workflows/{namespace}/{name} When using –auth-mode=sso, all Archived Workflows can be retrieved with a valid token via the GET Workflow endpoint: /api/v1/workflows/{namespace}/{name}

Due to a race condition in a global variable, the argo workflows controller can be made to crash on-command by any user with access to execute a workflow. This was resolved by https://github.com/argoproj/argo-workflows/pull/13641

Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. The attacker creates a workflow that produces a HTML artifact that contains a HTML file that contains a script which uses XHR calls to interact with the Argo Server API. The attacker emails the deep-link to the artifact to their victim. The victim opens the link, the script starts running. As the script has access …

Impact This is pro-active fix. No know exploits exist. Impacted: You're running Kubernetes >= v1.19 You're running Argo Server It is configured to with –auth-mode=client Is not configured with –auth-mode=server You are not running Argo Server in Kubernetes pod. E.g. on bare metal or other VM. You're using client key to authenticate on the server. The server has more permissions that the connecting client's account. The client's authentication will be …

Impact We are not aware of any exploits. This is a pro-active fix. Impacted: You are running Argo Server < v3.0 with –secure=true or >= v3.0 with –secure unspecified (note - running in secure mode is recommended regardless). The attacker is within your network. If you expose Argo Server to the Internet then "your network" is "the Internet". The Argo Server's keys are packaged within the image. They could be …

In Argo Workflows through 3.1.3, if EXPRESSION_TEMPLATES is enabled and untrusted users are allowed to specify input parameters when running workflows, an attacker may be able to disrupt a workflow because expression template output is evaluated.