Argo Vulnerable to Unauthenticated Memory Exhaustion (DoS) in Webhook Interceptor
Severity: Medium Component: Webhook Interceptor (server/auth/webhook) Vulnerability Type: Denial of Service (DoS)
Severity: Medium Component: Webhook Interceptor (server/auth/webhook) Vulnerability Type: Denial of Service (DoS)
The workflow executor logs all artifact repository credentials (S3 access keys, secret keys, GCS service account keys, Azure account keys, Git passwords, etc.) in plaintext on artifact operation. Any user with read access to workflow pod logs can extract these credentials. Note: This is an incomplete fix of CVE-2025-62157
The Sync Service's ConfigMap-backed provider (server/sync/sync_cm.go) performs zero authorization checks on all CRUD operations (create, read, update, delete). Any authenticated user — including those using fake Bearer tokens — can create, read, update, and delete Kubernetes ConfigMaps containing synchronization limits.
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() …
A nil pointer dereference in server/auth/gatekeeper.go rbacAuthorization() causes a panic (denial of service) for SSO users whose claims match a namespace-level RBAC rule but not an SSO-namespace rule, when SSO_DELEGATE_RBAC_TO_NAMESPACE=true.
An unchecked array index in the pod informer's podGCFromPod() function causes a controller-wide panic when a workflow pod carries a malformed workflows.argoproj.io/pod-gc-strategy annotation. Because the panic occurs inside an informer goroutine (outside the controller's recover() scope), it crashes the entire controller process. The poisoned pod persists across restarts, causing a crash loop that halts all workflow processing until the pod is manually deleted.
Workflow templates endpoints allow any client to retrieve WorkflowTemplates (and ClusterWorkflowTemplates). Any request with a Authorization: Bearer nothing token can leak sensitive template content, including embedded Secret manifests.
A user who can submit Workflows can completely bypass all security settings defined in a WorkflowTemplate by including a podSpecPatch field in their Workflow submission. This works even when the controller is configured with templateReferencing: Strict, which is specifically documented as a mechanism to restrict users to admin-approved templates. The podSpecPatch field on a submitted Workflow takes precedence over the referenced WorkflowTemplate during spec merging and is applied directly to …