Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/argoproj/argo-workflows/v4 >= 4.0.0, < 4.0.5
Fixed in
4.0.5· Vendor fix available
Issue
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 Details The logging driver passes the entire ArtifactDriver struct to the structured logger, for example: https://github.com/argoproj/argo-workflows/blob/59f1089b9875723ddffd524513e6bd5cb37e5e31/workflow/artifacts/logging/driver.go#L24 Exposed credential fields: - S3 (workflow/artifacts/s3/s3.go): AccessKey, SecretKey, SessionToken, ServerSideCustomerKey - OSS (workflow/artifacts/oss/oss.go): AccessKey, SecretKey, SecurityToken - GCS (workflow/artifacts/gcs/gcs.go): ServiceAccountKey PoC 1. Create template 2. Then check the logs kubectl -n argo logs "cred-leak-test" -c wait <img width="1248" height="322" alt="image"…
Recommended action: Upgrade to 4.0.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/argoproj/argo-workflows/v4 >= 4.0.0, < 4.0.5
Fixed in
4.0.5· Vendor fix available
Issue
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: 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…
Recommended action: Upgrade to 4.0.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/argoproj/argo-workflows/v4 >= 4.0.0, < 4.0.5
Fixed in
4.0.5· Vendor fix available
Issue
Severity: Medium Component: Webhook Interceptor (server/auth/webhook) Vulnerability Type: Denial of Service (DoS) Description The Webhook Interceptor loads the entire request body into memory before authenticating the request or verifying its signature. This occurs on the /api/v1/events/ endpoint, which is publicly accessible (albeit intended for webhooks). An attacker can send a request with an extremely large body (e.g., multiple gigabytes), causing the Argo Server to allocate excessive memory, potentially leading to an Out-Of-Memory (OOM) crash and denial of service. Vulnerable Code In server/auth/webhook/interceptor.go: The io.ReadAll call happens before the signature verification loop. Impact - Service Availability: An attacker can crash the Argo Server, disrupting workflow execution and API access for all users. PoC (Conceptual) 1. Target the webhook endpoint: POST /api/v1/events/some-namespace 2. Send a Content-Length: 1000000000 (1GB) header. 3. Stream 1GB of random data. 4.…
Recommended action: Upgrade to 4.0.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/argoproj/argo-workflows/v4 >= 4.0.0, <= 4.0.4
Fixed in
4.0.5· Vendor fix available
Issue
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 SSODELEGATERBACTONAMESPACE=true. Details When getServiceAccount(claims, ssoNamespace) returns nil (no matching rule), the error is suppressed and loginAccount remains nil. If RBAC delegation finds a matching namespaceAccount, line 304 calls precedence(loginAccount) which unconditionally accesses serviceAccount.Annotations — nil pointer dereference. Affected code (v4.0.4): PoC Live-tested 2026-04-17: kind cluster, Argo Workflows v4.0.4, Dex v2.43.1 OIDC provider. 1. Deploy Argo Workflows with --auth-mode=sso --auth-mode=client, SSO pointing to Dex, RBAC enabled. 2. Set SSODELEGATERBACTONAMESPACE=true on the argo-server deployment. 3. Create an RBAC ServiceAccount with workflows.argoproj.io/rbac-rule: "true" annotation in a target namespace (e.g., target-ns). 4. Do not…
Recommended action: Upgrade to 4.0.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/argoproj/argo-workflows/v4 >= 4.0.0, < 4.0.5
Fixed in
4.0.5· Vendor fix available
Issue
The Sync Service's ConfigMap-backed provider (server/sync/synccm.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. Details The ConfigMap-backed provider (server/sync/synccm.go) has no auth.CanI checks: - server/sync/synccm.go — lines 23-155 - All four SyncService endpoints: CreateSyncLimit, GetSyncLimit, UpdateSyncLimit, DeleteSyncLimit PoC Prerequisites - Argo Server running with --auth-mode=server - Port-forward: kubectl port-forward -n argo svc/argo-server 2746:2746 Step 1: Create Sync Limit (Fake Token) Result: {"namespace":"default","cmName":"test-sync","key":"test-key","limit":5} Verify ConfigMap was created in Kubernetes: Step 2: Read Sync Limit (Fake Token) Result: {"namespace":"default","cmName":"test-sync","key":"test-key","limit":5} Step 3: Update Sync Limit…
Recommended action: Upgrade to 4.0.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/argoproj/argo-workflows/v4 >= 4.0.0, < 4.0.5
Fixed in
4.0.5· Partial vendor fix
Issue
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. Details podGCFromPod() splits the annotation value on "/" and unconditionally accesses parts[1]: If the annotation value contains no "/", parts has length 1 and parts[1] panics with index out of range. The code was introduced in #14129 and affects versions: - 3.6.x: v3.6.5 through v3.6.19 (backport in #14263) - 3.7.x: v3.7.0-rc1 through v3.7.12 - 4.x: v4.0.0-rc1 through v4.0.3 - Not affected: v3.6.4 and earlier PoC Apply this workflow to a cluster running the Argo Workflows controller: Within seconds the controller…
Recommended action: Upgrade to 4.0.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details https://github.com/argoproj/argo-workflows/blob/b519c9054e66b2f0a25eec06709717bd1362f72e/server/workflowtemplate/workflowtemplateserver.go#L60-L78 https://github.com/argoproj/argo-workflows/blob/b519c9054e66b2f0a25eec06709717bd1362f72e/server/clusterworkflowtemplate/clusterworkflowtemplateserver.go#L54-L72 Informers use the server’s rest config, so they read using server SA privileges. https://github.com/argoproj/argo-workflows/blob/b519c9054e66b2f0a25eec06709717bd1362f72e/server/workflowtemplate/informer.go#L29-L42 https://github.com/argoproj/argo-workflows/blob/b519c9054e66b2f0a25eec06709717bd1362f72e/server/clusterworkflowtemplate/informer.go#L34-L46 PoC 1. Create template Then apply that with kubectl apply -f poc.yml 2. Query Argo…
Recommended action: Upgrade to 4.0.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.