Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
12 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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: Everything else passes through. createWorkflowPod reads hostNetwork, securityContext, serviceAccountName, tolerations, and automountServiceAccountToken from the merged spec and applies them directly to the pod. JoinWorkflowSpec constructs the merge target from the user's spec and applies the template as a patch -- user fields take priority. When the template doesn't explicitly set a field like hostNetwork (most won't -- false is the zero value and gets omitted), the user's true survives. For fields…
Recommended action: Upgrade to 3.7.14 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Severity: Medium Component: Webhook Interceptor (server/auth/webhook) Vulnerability Type: Denial of Service (DoS) Description The Webhook Interceptor loads the entire request body into memory before authenticating the request or verifying its signature. This occurs on the /api/v1/events/ endpoint, which is publicly accessible (albeit intended for webhooks). An attacker can send a request with an extremely large body (e.g., multiple gigabytes), causing the Argo Server to allocate excessive memory, potentially leading to an Out-Of-Memory (OOM) crash and denial of service. Vulnerable Code In server/auth/webhook/interceptor.go: The io.ReadAll call happens before the signature verification loop. Impact - Service Availability: An attacker can crash the Argo Server, disrupting workflow execution and API access for all users. PoC (Conceptual) 1. Target the webhook endpoint: POST /api/v1/events/some-namespace 2. Send a Content-Length: 1000000000 (1GB) header. 3. Stream 1GB of random data. 4.…
Recommended action: Upgrade to 3.7.14 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/argoproj/argo-workflows/v3 >= 3.7.0, < 3.7.14; >= 3.6.5, <= 3.6.19
Fixed in
3.7.14· Partial vendor fix
Issue
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. Details podGCFromPod() splits the annotation value on "/" and unconditionally accesses parts[1]: If the annotation value contains no "/", parts has length 1 and parts[1] panics with index out of range. The code was introduced in #14129 and affects versions: - 3.6.x: v3.6.5 through v3.6.19 (backport in #14263) - 3.7.x: v3.7.0-rc1 through v3.7.12 - 4.x: v4.0.0-rc1 through v4.0.3 - Not affected: v3.6.4 and earlier PoC Apply this workflow to a cluster running the Argo Workflows controller: Within seconds the controller…
Recommended action: Upgrade to 3.7.14; some affected versions have no fix yet, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/argoproj/argo-workflows/v3 >= 3.7.0, < 3.7.11
Fixed in
3.7.11· Vendor fix available
Issue
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. Details https://github.com/argoproj/argo-workflows/blob/b519c9054e66b2f0a25eec06709717bd1362f72e/server/workflowtemplate/workflowtemplateserver.go#L60-L78 https://github.com/argoproj/argo-workflows/blob/b519c9054e66b2f0a25eec06709717bd1362f72e/server/clusterworkflowtemplate/clusterworkflowtemplateserver.go#L54-L72 Informers use the server’s rest config, so they read using server SA privileges. https://github.com/argoproj/argo-workflows/blob/b519c9054e66b2f0a25eec06709717bd1362f72e/server/workflowtemplate/informer.go#L29-L42 https://github.com/argoproj/argo-workflows/blob/b519c9054e66b2f0a25eec06709717bd1362f72e/server/clusterworkflowtemplate/informer.go#L34-L46 PoC 1. Create template Then apply that with kubectl apply -f poc.yml 2. Query Argo…
Recommended action: Upgrade to 3.7.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/argoproj/argo-workflows/v3 >= 3.7.0, < 3.7.3; < 3.6.12
Fixed in
3.6.123.7.3· Vendor fix available
Issue
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. Details An attacker, by reading the logs of the workflow controller pod, can access the artifact repository, and steal, delete or modify the data that resides there. The workflow-controller logs show the credentials in plaintext. <img width="1366" alt="screen" src="https://github.com/user-attachments/assets/5642b2be-edcf-4050-bf47-747d05352698" / Impact An attacker with access to pod logs in the argo namespace can extract plaintext credentials from the workflow-controller logs and gain access to the artifact repository. This can lead to: - Data exfiltration – theft of sensitive or proprietary artifacts - Data tampering – modification of workflows or artifacts - Data destruction – deletion of stored artifacts, leading to potential loss of critical data or pipeline failure
Recommended action: Upgrade to 3.7.3 or 3.6.12 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/argoproj/argo-workflows/v3 < 3.6.12; >= 3.7.0, < 3.7.3
Fixed in
3.6.123.7.3· Vendor fix available
Issue
Vulnerability Description Vulnerability Overview 1. During the artifact extraction process, the unpack() function extracts the compressed file to a temporary directory (/etc.tmpdir) and then attempts to move its contents to /etc using the rename() system call, 2. However, since /etc is an already existing system directory, the rename() system call fails, making normal archive extraction impossible. 3. At this point, if a malicious user sets the entry name inside the tar.gz file to a path traversal like ../../../../../etc/zipslip-poc, 4. The untar() function combines paths using filepath.Join(dest, filepath.Clean(header.Name)) without path validation, resulting in target = "/work/input/../../../../../etc/zipslip-poc", 5. Ultimately, the /etc/zipslip-poc file is created, bypassing the normal archive extraction constraints and enabling direct file writing to system directories. untar(): Writing Files Outside the Extraction Directory…
Recommended action: Upgrade to 3.7.3 or 3.6.12 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/argoproj/argo-workflows/v3 >= 3.5.7, < 3.5.13; >= 3.6.0, < 3.6.2
Fixed in
3.6.23.5.13· Vendor fix available
Issue
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} Details No authentication is performed by the Server itself on client tokens[^1]. Authentication & authorization is instead delegated to the k8s API server. However, the Workflow Archive does not interact with k8s, and so any token that looks valid will be considered authenticated, even if it is not a k8s token or even if the token has no RBAC for Argo. To handle the lack of pass-through k8s authN/authZ, the Workflow Archive specifically does the equivalent of a kubectl auth can-i check for respective methods. In #12736 / v3.5.7 and #13021 / v3.5.8, the auth check was accidentally removed on the GET Workflow endpoint's fallback to archived workflows on these…
Recommended action: Upgrade to 3.6.2 or 3.5.13 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/argoproj/argo-workflows/v3 >= 3.6.0-rc1, <= 3.6.0-rc1
Fixed in
3.6.0-rc2· Vendor fix available
Issue
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 Details These two lines introduce a data race in the underlying SPDY implementation of the Kubernetes API client. If a second request is made before the first completes, it results in a panic due to a null pointer. https://github.com/argoproj/argo-workflows/blob/ce7f9bfb9b45f009b3e85fabe5e6410de23c7c5f/workflow/metrics/metricsk8srequest.go#L49 https://github.com/argoproj/argo-workflows/blob/ce7f9bfb9b45f009b3e85fabe5e6410de23c7c5f/workflow/metrics/metricsk8srequest.go#L75 This appears to have been added in this commit https://github.com/argoproj/argo-workflows/commit/9756babd0ed589d1cd24592f05725f748f74130b / #13265 / v3.6.0-rc1 PoC With the KUBECONFIG variable set to an appropriate file with create permissions for the Workflow kind, execute the…
Recommended action: Upgrade to 3.6.0-rc2 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/argoproj/argo-workflows/v3 >= 2.6.0, < 3.2.11; >= 3.3.0, < 3.3.5
Fixed in
3.2.113.3.5· Vendor fix available
Issue
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 to the Argo Server API (as the victim), so may do the following (if the victim may): Read information about the victim’s workflows. Create or delete workflows. Notes: The attacker must be an insider: they must have access to the same cluster as the victim and must already be able to run their own workflows. The attacker must have an understanding of the victim’s system. They won’t be able to repeatedly probe due to the social engineering aspect. The attacker is likely leave an audit trail. We have seen no evidence of this in the wild. While the impact is high, it…
Recommended action: Upgrade to 3.3.5 or 3.2.11 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/argoproj/argo-workflows/v3 >= 3.0.0, < 3.0.9; >= 3.1.0, < 3.1.6
Fixed in
3.1.63.0.9· Vendor fix available
Issue
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 ignored and the server's authentication will be used. This will result in privilege escalation to that of the the server's account. Patches https://github.com/argoproj/argo-workflows/pull/6506 Workarounds None.
Recommended action: Upgrade to 3.1.6 or 3.0.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/argoproj/argo-workflows/v3 >= 3.0.0, < 3.0.9; >= 3.1.0, < 3.1.6
Fixed in
3.1.63.0.9· Vendor fix available
Issue
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 extracted and used to decrypt traffic, or forge requests. Patches https://github.com/argoproj/argo-workflows/pull/6540 Workarounds Make sure that your Argo Server service or pod are not directly accessible outside of your cluster. Put TLS load balancer in front of it. This was identified by engineers at Jetstack.io
Recommended action: Upgrade to 3.1.6 or 3.0.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/argoproj/argo-workflows/v3 >= 3.1.0, < 3.1.6
Fixed in
3.1.6· Vendor fix available
Issue
Impact Allow end-users to set input parameters, but otherwise expect workflows to be secure. Patches Not yet. Workarounds Set EXPRESSIONTEMPLATES=false for the workflow controller References https://github.com/argoproj/argo-workflows/issues/6441 For more information If you have any questions or comments about this advisory: Open an issue in example link to repo Email us at example email address
Recommended action: Upgrade to 3.1.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.