Argo Workflows
Monthly
Cross-namespace data disclosure in Argo Workflows 4.1.0 through 4.1.3 lets an authenticated user who holds only namespace-scoped 'list' permission on archived workflows bypass the cluster-scoped access review and read archived workflows from every other namespace they were never granted access to. The bypass is triggered by supplying a negated metadata.namespace field selector (e.g. 'metadata.namespace!=<own-namespace>') to ListArchivedWorkflows; the server validates the caller's SelfSubjectAccessReview against the caller's own namespace instead of evaluating the request as a cluster-wide list, so the negated selector silently widens the result set. Exposed data includes workflow spec arguments, parameter values, and annotations, which frequently carry secrets, registry credentials, and internal endpoint details; the impact is confidentiality-only and is most severe in genuinely multi-tenant clusters where namespaces are treated as trust boundaries. There is no confirmed active exploitation (not listed in CISA KEV) and no public exploit code identified at time of analysis, and the vendor has released a fixed version, so this is a substantiated but not mass-exploitation risk.
Privilege escalation in Argo Workflows before 3.7.15 and 4.0.6 lets a low-privileged user who can submit Workflows bypass the Strict/Secure templateReferencing protections and inject an arbitrary strategic-merge PodSpecPatch into the artifact garbage-collection pod. Because the fix for CVE-2026-31892 only walked top-level WorkflowSpec fields and allow-listed WorkflowSpec.ArtifactGC wholesale, its nested WorkflowLevelArtifactGC.PodSpecPatch flowed unmodified into util.ApplyPodSpecPatch, allowing an attacker to spawn a pod with privileged: true, hostPath volumes, hostNetwork: true, and an attacker-chosen image and command. This is an incomplete-fix regression; there is no public exploit identified at time of analysis and it is not in CISA KEV.
Denial of service in the Argo Workflows controller (versions 3.6.5 through 4.0.4, plus the 3.7.0-rc1 through 3.7.12 pre-releases) lets any user able to submit a workflow crash-loop the entire controller by attaching a malformed workflows.argoproj.io/pod-gc-strategy pod annotation that contains no '/' separator, triggering an out-of-range index panic in an informer goroutine that sits outside the controller's recover() scope. Because the poisoned pod persists across restarts, the controller enters CrashLoopBackOff and halts all workflow processing cluster-wide until the pod is manually deleted. A working proof-of-concept manifest is published in the GHSA advisory (SSVC exploitation status: poc), but there is no evidence of active exploitation and EPSS is very low at 0.04%.
Authorization bypass in Argo Workflows (2.9.0 through 4.0.1 and 3.7.x before 3.7.11) lets any user permitted to submit Workflows override admin-defined WorkflowTemplate security controls by attaching a podSpecPatch to their submission. Because podSpecPatch is merged with Workflow-spec precedence and applied to the pod with no security validation, even controllers locked down with templateReferencing: Strict can be circumvented to run arbitrary pod settings such as privileged: true. Publicly available exploit code exists, but EPSS is low (0.04%) and it is not in CISA KEV.
Information disclosure in Argo Workflows before 4.0.2 and 3.7.11 lets any unauthenticated client read WorkflowTemplates and ClusterWorkflowTemplates by sending a bogus 'Authorization: Bearer nothing' token, leaking embedded Secret manifests and other sensitive template content. The CVSS 3.1 base score is 7.5 (confidentiality-only, network, no privileges) and publicly available exploit code exists, though EPSS is very low (0.04%) and it is not in CISA KEV, indicating no confirmed widespread exploitation yet.
Stored cross-site scripting in Argo Workflows (CNCF Kubernetes workflow engine) before 3.6.17 and 3.7.8 lets any authenticated workflow author plant malicious JavaScript that executes in another user's browser under the Argo Server origin, hijacking the victim's session to perform privileged API actions on their behalf. Public exploit details exist via the GitHub Security Advisory (GHSA-cv78-6m8q-ph82), but there is no public exploit identified as weaponized and no CISA KEV listing; EPSS is very low at 0.05% (16th percentile). The flaw is patched in 3.6.17 and 3.7.8.
Malicious tar archives can escape Argo Workflows' artifact extraction directory and overwrite /var/run/argo/argoexec inside a workflow pod, allowing an attacker to substitute the executor binary with a script that runs when the pod starts. Only Argo Workflows 3.6.13 and earlier and 3.7.0 through 3.7.4 are affected (fixed in 3.6.14 and 3.7.5), and exploitation requires the attacker to get an attacker-influenced archive processed by the executor's untar routine, for example via an artifact store they control or a submitted workflow that pulls their tarball. Publicly available exploit code exists, but there is no confirmed active exploitation (not in CISA KEV) and EPSS is a modest 0.68% (51st percentile); the independent assessment rates this as a moderate-priority issue rather than an emergency. Notably, environments that only applied the earlier fix for CVE-2025-62156 remain vulnerable because that patch does not handle malicious symbolic links.
Argo Workflows versions prior to 3.6.12 and 3.7.0 through 3.7.2 write the artifact repository credentials held in the workflow-controller configuration to the controller pod's logs in plaintext, so anyone able to read those logs can recover the credentials and use them against the configured artifact store. Exploitation requires an authenticated Kubernetes principal holding RBAC permission to read pod logs (the pods/log 'get' verb) in the namespace running Argo Workflows, and the deployment must have an artifact repository configured with credentials (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N; vendor CVSS 4.0 base 8.5). No public exploit code has been identified at time of analysis, EPSS is low at 0.47% (38th percentile), and the issue is not listed in CISA KEV; fixes ship in 3.6.12 and 3.7.3.
Argo Workflows versions prior to 3.6.12 and 3.7.0 through 3.7.2 are vulnerable to a Zip Slip path traversal during artifact extraction, letting an authenticated workflow user craft a tar.gz entry that escapes the /work/tmp extraction path and writes files into system locations such as /etc inside the container. Because overwriting files like /etc/passwd, /etc/hosts, or /etc/crontab can grant elevated privileges or establish persistence within the affected container, the impact is high, though it is scoped to the container (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, 8.8). Publicly available exploit code exists, including a detailed proof-of-concept in the vendor's GHSA-p84v-gxvw-73pf advisory, but there is no confirmed active exploitation (not in CISA KEV); EPSS is 0.59% (47th percentile), indicating a credible but conditional rather than internet-wide emergency.
Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. Rated medium severity (CVSS 6.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. Rated medium severity (CVSS 4.8).
Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. Rated high severity (CVSS 7.1), this vulnerability is remotely exploitable. This Improper Privilege Management vulnerability could allow attackers to escalate privileges to gain unauthorized elevated access.
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. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
Cross-namespace data disclosure in Argo Workflows 4.1.0 through 4.1.3 lets an authenticated user who holds only namespace-scoped 'list' permission on archived workflows bypass the cluster-scoped access review and read archived workflows from every other namespace they were never granted access to. The bypass is triggered by supplying a negated metadata.namespace field selector (e.g. 'metadata.namespace!=<own-namespace>') to ListArchivedWorkflows; the server validates the caller's SelfSubjectAccessReview against the caller's own namespace instead of evaluating the request as a cluster-wide list, so the negated selector silently widens the result set. Exposed data includes workflow spec arguments, parameter values, and annotations, which frequently carry secrets, registry credentials, and internal endpoint details; the impact is confidentiality-only and is most severe in genuinely multi-tenant clusters where namespaces are treated as trust boundaries. There is no confirmed active exploitation (not listed in CISA KEV) and no public exploit code identified at time of analysis, and the vendor has released a fixed version, so this is a substantiated but not mass-exploitation risk.
Privilege escalation in Argo Workflows before 3.7.15 and 4.0.6 lets a low-privileged user who can submit Workflows bypass the Strict/Secure templateReferencing protections and inject an arbitrary strategic-merge PodSpecPatch into the artifact garbage-collection pod. Because the fix for CVE-2026-31892 only walked top-level WorkflowSpec fields and allow-listed WorkflowSpec.ArtifactGC wholesale, its nested WorkflowLevelArtifactGC.PodSpecPatch flowed unmodified into util.ApplyPodSpecPatch, allowing an attacker to spawn a pod with privileged: true, hostPath volumes, hostNetwork: true, and an attacker-chosen image and command. This is an incomplete-fix regression; there is no public exploit identified at time of analysis and it is not in CISA KEV.
Denial of service in the Argo Workflows controller (versions 3.6.5 through 4.0.4, plus the 3.7.0-rc1 through 3.7.12 pre-releases) lets any user able to submit a workflow crash-loop the entire controller by attaching a malformed workflows.argoproj.io/pod-gc-strategy pod annotation that contains no '/' separator, triggering an out-of-range index panic in an informer goroutine that sits outside the controller's recover() scope. Because the poisoned pod persists across restarts, the controller enters CrashLoopBackOff and halts all workflow processing cluster-wide until the pod is manually deleted. A working proof-of-concept manifest is published in the GHSA advisory (SSVC exploitation status: poc), but there is no evidence of active exploitation and EPSS is very low at 0.04%.
Authorization bypass in Argo Workflows (2.9.0 through 4.0.1 and 3.7.x before 3.7.11) lets any user permitted to submit Workflows override admin-defined WorkflowTemplate security controls by attaching a podSpecPatch to their submission. Because podSpecPatch is merged with Workflow-spec precedence and applied to the pod with no security validation, even controllers locked down with templateReferencing: Strict can be circumvented to run arbitrary pod settings such as privileged: true. Publicly available exploit code exists, but EPSS is low (0.04%) and it is not in CISA KEV.
Information disclosure in Argo Workflows before 4.0.2 and 3.7.11 lets any unauthenticated client read WorkflowTemplates and ClusterWorkflowTemplates by sending a bogus 'Authorization: Bearer nothing' token, leaking embedded Secret manifests and other sensitive template content. The CVSS 3.1 base score is 7.5 (confidentiality-only, network, no privileges) and publicly available exploit code exists, though EPSS is very low (0.04%) and it is not in CISA KEV, indicating no confirmed widespread exploitation yet.
Stored cross-site scripting in Argo Workflows (CNCF Kubernetes workflow engine) before 3.6.17 and 3.7.8 lets any authenticated workflow author plant malicious JavaScript that executes in another user's browser under the Argo Server origin, hijacking the victim's session to perform privileged API actions on their behalf. Public exploit details exist via the GitHub Security Advisory (GHSA-cv78-6m8q-ph82), but there is no public exploit identified as weaponized and no CISA KEV listing; EPSS is very low at 0.05% (16th percentile). The flaw is patched in 3.6.17 and 3.7.8.
Malicious tar archives can escape Argo Workflows' artifact extraction directory and overwrite /var/run/argo/argoexec inside a workflow pod, allowing an attacker to substitute the executor binary with a script that runs when the pod starts. Only Argo Workflows 3.6.13 and earlier and 3.7.0 through 3.7.4 are affected (fixed in 3.6.14 and 3.7.5), and exploitation requires the attacker to get an attacker-influenced archive processed by the executor's untar routine, for example via an artifact store they control or a submitted workflow that pulls their tarball. Publicly available exploit code exists, but there is no confirmed active exploitation (not in CISA KEV) and EPSS is a modest 0.68% (51st percentile); the independent assessment rates this as a moderate-priority issue rather than an emergency. Notably, environments that only applied the earlier fix for CVE-2025-62156 remain vulnerable because that patch does not handle malicious symbolic links.
Argo Workflows versions prior to 3.6.12 and 3.7.0 through 3.7.2 write the artifact repository credentials held in the workflow-controller configuration to the controller pod's logs in plaintext, so anyone able to read those logs can recover the credentials and use them against the configured artifact store. Exploitation requires an authenticated Kubernetes principal holding RBAC permission to read pod logs (the pods/log 'get' verb) in the namespace running Argo Workflows, and the deployment must have an artifact repository configured with credentials (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N; vendor CVSS 4.0 base 8.5). No public exploit code has been identified at time of analysis, EPSS is low at 0.47% (38th percentile), and the issue is not listed in CISA KEV; fixes ship in 3.6.12 and 3.7.3.
Argo Workflows versions prior to 3.6.12 and 3.7.0 through 3.7.2 are vulnerable to a Zip Slip path traversal during artifact extraction, letting an authenticated workflow user craft a tar.gz entry that escapes the /work/tmp extraction path and writes files into system locations such as /etc inside the container. Because overwriting files like /etc/passwd, /etc/hosts, or /etc/crontab can grant elevated privileges or establish persistence within the affected container, the impact is high, though it is scoped to the container (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, 8.8). Publicly available exploit code exists, including a detailed proof-of-concept in the vendor's GHSA-p84v-gxvw-73pf advisory, but there is no confirmed active exploitation (not in CISA KEV); EPSS is 0.59% (47th percentile), indicating a credible but conditional rather than internet-wide emergency.
Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. Rated medium severity (CVSS 6.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. Rated medium severity (CVSS 4.8).
Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. Rated high severity (CVSS 7.1), this vulnerability is remotely exploitable. This Improper Privilege Management vulnerability could allow attackers to escalate privileges to gain unauthorized elevated access.
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. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.