CVE-2026-42296: Argo has incomplete fix for CVE-2026-31892: hostNetwork, securityContext, serviceAccountName bypass templateReferencing Strict/Secure

The fix for CVE-2026-31892 (commit 534f4ff) blocks podSpecPatch when templateReferencing: Strict is active, but doesn’t restrict other WorkflowSpec fields that flow through the same merge path and get applied to pods. A user can set hostNetwork: true, override serviceAccountName, or change securityContext on their Workflow while referencing a hardened template – these survive JoinWorkflowSpec and get applied at pod creation.

The check in setExecWorkflow gates on HasPodSpecPatch() only:

if woc.controller.Config.WorkflowRestrictions.MustUseReference() && woc.wf.Spec.HasPodSpecPatch() {

Everything else passes through. createWorkflowPod reads hostNetwork, securityContext, serviceAccountName, tolerations, and automountServiceAccountToken from the merged spec and applies them directly to the pod.

JoinWorkflowSpec constructs the merge target from the user’s spec and applies the template as a patch – user fields take priority. When the template doesn’t explicitly set a field like hostNetwork (most won’t – false is the zero value and gets omitted), the user’s true survives. For fields like securityContext and serviceAccountName, the template-level value takes precedence IF the template explicitly sets it. The bypass applies when the template relies on defaults.

Both Strict and Secure modes are affected. Secure stores the merged spec on first submission, so user overrides get baked into the stored spec and subsequent MustNotChangeSpec comparisons pass.