Overview
A high-severity security bypass vulnerability has been disclosed in Argo Workflows, the popular open-source container-native workflow engine for orchestrating parallel jobs on Kubernetes. Tracked as CVE-2026-42296 with a CVSS score of 8.1, this flaw allows an authenticated user with create Workflow permissions to bypass the templateReferencing: Strict security control.
Successful exploitation enables an attacker to obtain host network access, switch service accounts, and override pod security contexts — significantly expanding an attacker's footprint within a Kubernetes cluster.
Affected Versions
| Branch | Fixed In |
|---|---|
| 3.x | 3.7.14 |
| 4.x | 4.0.5 |
All versions of Argo Workflows prior to 3.7.14 (3.x branch) and 4.0.5 (4.x branch) are considered vulnerable.
Technical Details
Argo Workflows provides a templateReferencing: Strict mode as a security boundary to prevent workflows from referencing templates outside of approved WorkflowTemplate resources. This mode is intended to restrict the scope of what a workflow can do, preventing privilege abuse by restricting which pod configurations and service accounts are permitted.
CVE-2026-42296 reveals that this boundary can be bypassed by a user who holds the create Workflow permission. Once bypassed, an attacker can:
- Access host network: By setting
hostNetwork: truein the pod spec, a malicious workflow can break out of the cluster's network namespace and communicate directly with the underlying node's network interfaces. - Switch service accounts: An attacker can specify arbitrary service accounts within the namespace, potentially adopting accounts with broader RBAC permissions.
- Override pod security contexts: Security constraints such as
runAsNonRoot,readOnlyRootFilesystem, and seccomp/AppArmor profiles can be bypassed, enabling privileged containers.
Together, these capabilities could allow an attacker to escalate from a normal Kubernetes user to a node-level compromise in environments where Argo Workflows is deployed without strict network policies or admission controls.
Impact Assessment
The vulnerability is rated High (CVSS 8.1) due to:
- Confidentiality Impact: High — attacker gains access to host network traffic and secrets in other namespaces via service account pivoting.
- Integrity Impact: High — the attacker can deploy arbitrary workloads and modify cluster state.
- Availability Impact: Low — no direct denial-of-service capability introduced.
- Attack Vector: Network — requires authenticated access with
create WorkflowRBAC permission. - Privileges Required: Low — only standard Workflow create permissions needed.
Recommended Actions
Immediate Mitigations
- Upgrade immediately: Update Argo Workflows to version 3.7.14 (for 3.x deployments) or 4.0.5 (for 4.x deployments).
- Audit RBAC permissions: Review and restrict which users and service accounts have
create Workflowpermissions. Apply the principle of least privilege. - Enable admission controls: Deploy OPA Gatekeeper, Kyverno, or a similar admission controller to enforce pod security policies independently of Argo's
templateReferencingfeature. - Apply PodSecurity Standards: Use Kubernetes Pod Security Admission (
enforce: restricted) at the namespace level to blockhostNetworkand privileged pod specs at the API server level. - Monitor for anomalous workflows: Audit existing workflows for unusual
hostNetwork: trueor elevated security context settings.
If Upgrade Is Not Immediately Possible
- Temporarily restrict
create Workflowpermissions to only highly trusted users and service accounts. - Consider enabling Kubernetes
NetworkPolicyto limit lateral movement even if host network access is obtained. - Review Argo Server RBAC mode and ensure SSO/OAuth is enabled rather than relying on
serverorclientauth modes.
References
- NVD — CVE-2026-42296
- Argo Workflows GitHub Security Advisories
- Argo Workflows Releases
- Kubernetes Pod Security Admission