CVE-2026-42296: CWE-863: Incorrect Authorization in argoproj argo-workflows
Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. Prior to versions 3.7.14 and 4.0.5, a user with create Workflow permission can bypass templateReferencing: Strict to get host network access, switch service accounts, override pod security context, add tolerations to schedule on control-plane nodes, or enable SA token mounting. This defeats the stated purpose of the feature. The practical impact depends on what Kubernetes-level controls are in place. Clusters with PodSecurity admission or OPA/Gatekeeper would independently block some of these (like hostNetwork). Clusters that rely on Argo's Strict mode as the primary enforcement layer are fully exposed. This issue has been patched in versions 3.7.14 and 4.0.5.
AI Analysis
Technical Summary
Argo Workflows before versions 3.7.14 and 4.0.5 contains an incorrect authorization vulnerability (CWE-863) where users granted create Workflow permission can bypass the templateReferencing: Strict enforcement. This bypass permits escalation of privileges such as accessing the host network, switching service accounts, overriding pod security contexts, adding tolerations to schedule on control-plane nodes, and enabling service account token mounting. The vulnerability undermines the intended security controls of the Strict mode feature. The practical exploitation impact depends on additional Kubernetes cluster-level security controls like PodSecurity admission or OPA/Gatekeeper, which may block some actions. Clusters relying solely on Argo's Strict mode are fully exposed. The vulnerability has been fixed in Argo Workflows versions 3.7.14 and 4.0.5. No known exploits in the wild have been reported. The CVSS v3.1 score is 8.1 (High), reflecting network attack vector, low attack complexity, required privileges, no user interaction, and high confidentiality and integrity impact.
Potential Impact
An attacker with create Workflow permission can bypass Argo Workflows' templateReferencing: Strict security feature, potentially gaining unauthorized host network access, switching service accounts, overriding pod security contexts, scheduling pods on control-plane nodes, and enabling service account token mounting. This can lead to significant confidentiality and integrity impacts within the Kubernetes cluster. The severity of the impact depends on additional Kubernetes-level security controls; clusters without such controls relying solely on Argo's Strict mode are fully exposed to these risks.
Mitigation Recommendations
A fix for this vulnerability is available in Argo Workflows versions 3.7.14 and 4.0.5. Users should upgrade to these versions or later to remediate the issue. Additionally, Kubernetes clusters should enforce PodSecurity admission or use OPA/Gatekeeper policies to provide defense-in-depth. Since the vendor advisory does not specify alternative mitigations or indicate that no action is required, upgrading is the recommended remediation.
CVE-2026-42296: CWE-863: Incorrect Authorization in argoproj argo-workflows
Description
Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. Prior to versions 3.7.14 and 4.0.5, a user with create Workflow permission can bypass templateReferencing: Strict to get host network access, switch service accounts, override pod security context, add tolerations to schedule on control-plane nodes, or enable SA token mounting. This defeats the stated purpose of the feature. The practical impact depends on what Kubernetes-level controls are in place. Clusters with PodSecurity admission or OPA/Gatekeeper would independently block some of these (like hostNetwork). Clusters that rely on Argo's Strict mode as the primary enforcement layer are fully exposed. This issue has been patched in versions 3.7.14 and 4.0.5.
CVSS v3.1
Score 8.1high
Affected software
pkg:github/argoproj/argo-workflowsRun on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
Argo Workflows before versions 3.7.14 and 4.0.5 contains an incorrect authorization vulnerability (CWE-863) where users granted create Workflow permission can bypass the templateReferencing: Strict enforcement. This bypass permits escalation of privileges such as accessing the host network, switching service accounts, overriding pod security contexts, adding tolerations to schedule on control-plane nodes, and enabling service account token mounting. The vulnerability undermines the intended security controls of the Strict mode feature. The practical exploitation impact depends on additional Kubernetes cluster-level security controls like PodSecurity admission or OPA/Gatekeeper, which may block some actions. Clusters relying solely on Argo's Strict mode are fully exposed. The vulnerability has been fixed in Argo Workflows versions 3.7.14 and 4.0.5. No known exploits in the wild have been reported. The CVSS v3.1 score is 8.1 (High), reflecting network attack vector, low attack complexity, required privileges, no user interaction, and high confidentiality and integrity impact.
Potential Impact
An attacker with create Workflow permission can bypass Argo Workflows' templateReferencing: Strict security feature, potentially gaining unauthorized host network access, switching service accounts, overriding pod security contexts, scheduling pods on control-plane nodes, and enabling service account token mounting. This can lead to significant confidentiality and integrity impacts within the Kubernetes cluster. The severity of the impact depends on additional Kubernetes-level security controls; clusters without such controls relying solely on Argo's Strict mode are fully exposed to these risks.
Mitigation Recommendations
A fix for this vulnerability is available in Argo Workflows versions 3.7.14 and 4.0.5. Users should upgrade to these versions or later to remediate the issue. Additionally, Kubernetes clusters should enforce PodSecurity admission or use OPA/Gatekeeper policies to provide defense-in-depth. Since the vendor advisory does not specify alternative mitigations or indicate that no action is required, upgrading is the recommended remediation.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- GitHub_M
- Date Reserved
- 2026-04-26T12:13:55.552Z
- Cvss Version
- 3.1
- State
- PUBLISHED
- Remediation Level
- null
- Vendor Advisory Urls
- [{"url":"https://access.redhat.com/security/cve/CVE-2026-42296","vendor":"Red Hat"}]
Threat ID: 69ffe1b2cbff5d8610ead443
Added to database: 05/10/2026, 01:38:58 UTC
Last enriched: 07/15/2026, 09:16:16 UTC
Last updated: 08/17/2026, 12:41:17 UTC
Views: 243
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.