Which versions of Argo Workflows are affected by CVE-2026-54526?

Argo Workflows versions before 3.7.15 and 4.0.6 contain a privilege escalation vulnerability (CVSS 8.9) that allows low-privileged users with workflow submission rights to bypass security controls…. A patch is available.

Is there a public PoC exploit available for CVE-2026-54526?

Yes, a public proof-of-concept exploit is available for CVE-2026-54526. Prioritise patching immediately. EPSS: 0.2%.

How to fix or mitigate CVE-2026-54526?

Within 24 hours: inventory all Argo Workflows deployments and identify versions prior to 3.7.15 (v3 track) or 4.0.6 (v4 track); audit RBAC policies to determine which users and service accounts currently have permission to submit workflows. Within 7 days: implement restrictive RBAC policies limiting workflow submission to named administrative accounts only; enable Pod Security Policy or Pod Security Standards to deny privileged containers, host networking, and host path volume mounting; activate comprehensive audit logging for workflow submissions and pod creation events. Within 30 days: establish continuous monitoring of the Argo project for patch availability; test Argo Workflows 3.7.15+ or 4.0.6+ in staging; plan and execute production upgrades with rollback procedures.

Argo Workflows CVE-2026-54526

Q: What is the CVSS score of CVE-2026-54526?

CVE-2026-54526 has a CVSS 4.0 base score of 8.9 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.2%.

EUVD-2026-45029 HIGH

Improper Access Control (CWE-284)

2026-07-16 security-advisories@github.com

GHSA-48p8-g2fx-3wwm

Authentication Bypass Kubernetes Argo Workflows

8.9

CVSS 4.0 · Vendor: github

Severity by source

Vendor (github) PRIMARY

8.9 HIGH

CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

8.5 HIGH

Authenticated workflow submitter (PR:L) over the API (AV:N); AC:H because a specific referenced-template + artifact-GC configuration is required; privileged pod escapes to the node (S:C) with full C/I/A impact.

3.1 AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H

4.0 AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

Primary rating from Vendor (github).

CVSS VectorVendor: github

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Lifecycle Timeline

Patch available

Jul 16, 2026 - 22:19 EUVD

Source Code Evidence Fetched

Jul 16, 2026 - 19:32 vuln.today

Analysis Generated

Jul 16, 2026 - 19:32 vuln.today

CVE Published

Jul 16, 2026 - 19:16 cve.org

HIGH 8.9

DescriptionCVE.org

Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. Prior to 3.7.15 and 4.0.6, the allow-list fix for CVE-2026-31892 is incomplete because workflow/util/merge.go ValidateUserOverrides and SanitizeUserWorkflowSpec walk only the top-level fields of WorkflowSpec via reflection, and WorkflowSpec.ArtifactGC is allow-listed wholesale; the struct behind that field, WorkflowLevelArtifactGC, has a PodSpecPatch sub-field whose contents flow unmodified into util.ApplyPodSpecPatch on the artifact-GC pod, the same sink the original fix closed for WorkflowSpec.PodSpecPatch, so a user submitting a Workflow under templateReferencing: Strict or Secure (against a referenced WorkflowTemplate that declares an output artifact and setting spec.artifactGC.strategy: OnWorkflowCompletion) can still inject an arbitrary strategic merge patch into the artifact-GC pod, including hostPath volumes, privileged: true, arbitrary image and command, and hostNetwork: true, defeating the stated purpose of Strict/Secure reference mode. This issue is fixed in versions 3.7.15 and 4.0.6.

Articles & Coverage 1

News 5 New Kubernetes Vulnerabilities - 1 Critical, 4 High, 1 With POC Jul 17, 2026

AnalysisAI

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.

Technical ContextAI

Argo Workflows is a CNCF-graduated, container-native workflow engine that runs parallel job DAGs as pods on Kubernetes. The vulnerability lives in workflow/util/merge.go, where ValidateUserOverrides and SanitizeUserWorkflowSpec enforce the Strict/Secure reference model that is supposed to prevent a user-submitted Workflow from overriding security-sensitive fields of a referenced WorkflowTemplate. These functions use reflection that only inspects the top-level fields of WorkflowSpec, and WorkflowSpec.ArtifactGC (type WorkflowLevelArtifactGC) was allow-listed as a whole so its benign Strategy/ForceFinalizerRemoval fields could be set. However that struct also carries PodSpecPatch, ServiceAccountName, and PodMetadata sub-fields that reach the artifact-GC pod through util.ApplyPodSpecPatch - the exact sink the original CVE-2026-31892 fix closed for the top-level WorkflowSpec.PodSpecPatch. The root cause maps to CWE-284 (Improper Access Control): an allow-list that fails to recurse into nested structures, so a strategic merge patch can override the pod's container image, command, and securityContext. The fix commit adds artifactGCOverrideViolations (validation-time rejection) and sanitizeArtifactGC (defense-in-depth stripping) for those three nested fields.

RemediationAI

Vendor-released patch: upgrade to Argo Workflows 3.7.15 (3.x users) or 4.0.6 (4.x users), per GHSA-48p8-g2fx-3wwm and fix commits 277e9cef0ad16d7eaaab253573d0695951a65dbd and 358cc3968c8f06f1be0967e41df191088db0b662; these add validation-time rejection and sanitization of ArtifactGC.PodSpecPatch, ArtifactGC.ServiceAccountName, and ArtifactGC.PodMetadata. If you cannot upgrade immediately, the concrete compensating controls are: stop relying on Strict/Secure reference mode as a trust boundary for untrusted submitters and restrict who can create/submit Workflows (tighten Argo RBAC and the workflow-controller's submit permissions), which trades away self-service workflow submission; disable workflow-level artifact garbage collection (do not set spec.artifactGC.strategy, or remove output artifacts from referenced templates) so the vulnerable artifact-GC pod is never created, at the cost of losing automatic artifact cleanup; and constrain the blast radius with a restrictive PodSecurity admission policy / OPA-Gatekeeper or Kyverno rule that denies privileged: true, hostPath, and hostNetwork pods in the Argo namespace, which limits escalation but may block other legitimately privileged workloads. Advisory: https://github.com/argoproj/argo-workflows/security/advisories/GHSA-48p8-g2fx-3wwm.