{"url":"http://public2.vulnerablecode.io/api/vulnerabilities/95075?format=json","vulnerability_id":"VCID-585r-zpf1-pffu","summary":"Argo has incomplete fix for CVE-2026-31892: hostNetwork, securityContext, serviceAccountName bypass templateReferencing Strict/Secure\nThe 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.","aliases":[{"alias":"CVE-2026-42296"},{"alias":"GHSA-3775-99mw-8rp4"}],"fixed_packages":[{"url":"http://public2.vulnerablecode.io/api/packages/110913?format=json","purl":"pkg:golang/github.com/argoproj/argo-workflows/v3@3.7.14","is_vulnerable":false,"affected_by_vulnerabilities":[],"resource_url":"http://public2.vulnerablecode.io/packages/pkg:golang/github.com/argoproj/argo-workflows/v3@3.7.14"},{"url":"http://public2.vulnerablecode.io/api/packages/110912?format=json","purl":"pkg:golang/github.com/argoproj/argo-workflows/v4@4.0.5","is_vulnerable":false,"affected_by_vulnerabilities":[],"resource_url":"http://public2.vulnerablecode.io/packages/pkg:golang/github.com/argoproj/argo-workflows/v4@4.0.5"}],"affected_packages":[],"references":[{"reference_url":"https://api.first.org/data/v1/epss?cve=CVE-2026-42296","reference_id":"","reference_type":"","scores":[{"value":"0.00035","scoring_system":"epss","scoring_elements":"0.106","published_at":"2026-06-09T12:55:00Z"},{"value":"0.00035","scoring_system":"epss","scoring_elements":"0.10579","published_at":"2026-06-08T12:55:00Z"},{"value":"0.00035","scoring_system":"epss","scoring_elements":"0.10663","published_at":"2026-06-07T12:55:00Z"},{"value":"0.00035","scoring_system":"epss","scoring_elements":"0.10701","published_at":"2026-06-06T12:55:00Z"},{"value":"0.00035","scoring_system":"epss","scoring_elements":"0.10677","published_at":"2026-06-05T12:55:00Z"}],"url":"https://api.first.org/data/v1/epss?cve=CVE-2026-42296"},{"reference_url":"https://github.com/argoproj/argo-workflows","reference_id":"","reference_type":"","scores":[{"value":"8.1","scoring_system":"cvssv3.1","scoring_elements":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N"},{"value":"HIGH","scoring_system":"generic_textual","scoring_elements":""}],"url":"https://github.com/argoproj/argo-workflows"},{"reference_url":"https://github.com/argoproj/argo-workflows/commit/2727f3f701677d467dfb5e053c57237cbc752c3c","reference_id":"","reference_type":"","scores":[{"value":"8.1","scoring_system":"cvssv3.1","scoring_elements":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N"},{"value":"HIGH","scoring_system":"generic_textual","scoring_elements":""}],"url":"https://github.com/argoproj/argo-workflows/commit/2727f3f701677d467dfb5e053c57237cbc752c3c"},{"reference_url":"https://github.com/argoproj/argo-workflows/commit/534f4ff1cbd86908e8ff76d97d553ad5a49a950d","reference_id":"","reference_type":"","scores":[{"value":"8.1","scoring_system":"cvssv3.1","scoring_elements":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N"},{"value":"HIGH","scoring_system":"generic_textual","scoring_elements":""},{"value":"Track*","scoring_system":"ssvc","scoring_elements":"SSVCv2/E:P/A:N/T:T/P:M/B:A/M:M/D:R/2026-05-12T17:51:11Z/"}],"url":"https://github.com/argoproj/argo-workflows/commit/534f4ff1cbd86908e8ff76d97d553ad5a49a950d"},{"reference_url":"https://github.com/argoproj/argo-workflows/releases/tag/v3.7.14","reference_id":"","reference_type":"","scores":[{"value":"8.1","scoring_system":"cvssv3.1","scoring_elements":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N"},{"value":"HIGH","scoring_system":"generic_textual","scoring_elements":""},{"value":"Track*","scoring_system":"ssvc","scoring_elements":"SSVCv2/E:P/A:N/T:T/P:M/B:A/M:M/D:R/2026-05-12T17:51:11Z/"}],"url":"https://github.com/argoproj/argo-workflows/releases/tag/v3.7.14"},{"reference_url":"https://github.com/argoproj/argo-workflows/releases/tag/v4.0.5","reference_id":"","reference_type":"","scores":[{"value":"8.1","scoring_system":"cvssv3.1","scoring_elements":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N"},{"value":"HIGH","scoring_system":"generic_textual","scoring_elements":""},{"value":"Track*","scoring_system":"ssvc","scoring_elements":"SSVCv2/E:P/A:N/T:T/P:M/B:A/M:M/D:R/2026-05-12T17:51:11Z/"}],"url":"https://github.com/argoproj/argo-workflows/releases/tag/v4.0.5"},{"reference_url":"https://github.com/argoproj/argo-workflows/security/advisories/GHSA-3775-99mw-8rp4","reference_id":"","reference_type":"","scores":[{"value":"8.1","scoring_system":"cvssv3.1","scoring_elements":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N"},{"value":"HIGH","scoring_system":"generic_textual","scoring_elements":""},{"value":"Track*","scoring_system":"ssvc","scoring_elements":"SSVCv2/E:P/A:N/T:T/P:M/B:A/M:M/D:R/2026-05-12T17:51:11Z/"}],"url":"https://github.com/argoproj/argo-workflows/security/advisories/GHSA-3775-99mw-8rp4"},{"reference_url":"https://github.com/argoproj/argo-workflows/security/advisories/GHSA-3wf5-g532-rcrr","reference_id":"","reference_type":"","scores":[{"value":"8.1","scoring_system":"cvssv3.1","scoring_elements":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N"},{"value":"HIGH","scoring_system":"generic_textual","scoring_elements":""}],"url":"https://github.com/argoproj/argo-workflows/security/advisories/GHSA-3wf5-g532-rcrr"},{"reference_url":"https://nvd.nist.gov/vuln/detail/CVE-2026-42296","reference_id":"","reference_type":"","scores":[{"value":"8.1","scoring_system":"cvssv3.1","scoring_elements":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N"},{"value":"HIGH","scoring_system":"generic_textual","scoring_elements":""}],"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-42296"}],"weaknesses":[{"cwe_id":863,"name":"Incorrect Authorization","description":"The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. This allows attackers to bypass intended access restrictions."}],"exploits":[],"severity_range_score":"7.0 - 8.9","exploitability":null,"weighted_severity":null,"risk_score":null,"resource_url":"http://public2.vulnerablecode.io/vulnerabilities/VCID-585r-zpf1-pffu"}