Argo Workflows CVE-2025-62157

Requires a vulnerable Argo Workflows deployment (< 3.6.12 or 3.7.0 through 3.7.2) that has an artifact repository configured with credentials, since those credentials are what the workflow-controller marshals into its config and writes to the pod logs. The attacker must hold Kubernetes RBAC permission to read pod logs (the pods/log 'get' verb) in the namespace running Argo Workflows - this authenticated, privileged access is the primary limiting factor. There is no user interaction and no need for a crafted payload. Exploitation is NOT possible against patched versions (3.6.12 / 3.7.3), and no workarounds exist for unpatched versions other than restricting pod-log RBAC and rotating any already-exposed artifact repository credentials.

This is a credential-disclosure flaw (CWE-522) in Argo Workflows where the workflow-controller marshals its entire configuration - including artifact repository credentials - into plaintext pod logs. The signals are consistent and point to a moderate, conditional risk rather than an urgent internet-facing emergency. The vendor CVSS 4.0 vector (AV:N/AC:L/PR:H/UI:N, VC:H/VI:H) correctly reflects that exploitation is low-complexity but gated behind a meaningful privilege: the attacker must already hold Kubernetes RBAC rights to read pod logs in the namespace running Argo. EPSS is low (0.47%, 38th percentile) and there is no CISA KEV listing and no public exploit, which aligns with the PR:H gating - this is an insider/lateral-movement or post-compromise credential-harvesting issue, not a mass-exploitable remote bug. The AV:N labeling is technically accurate (the Kubernetes API is reached over the network) but should not be read as 'unauthenticated remote' - it still requires authenticated, privileged API access. Note one point to verify: the vendor rates privileges as PR:H, but reading pod logs is often a delegated, non-administrative RBAC grant, so the effective privilege barrier may be closer to PR:L in environments that hand out broad log-read access - defenders should check their RBAC bindings rather than assume only cluster-admins are affected. Net: a real, worth-patching issue because the leaked credentials enable theft, tampering, or destruction of artifact-repository data, but not a drop-everything priority absent evidence of active exploitation.

A developer or service account in the Argo (e.g. 'argo') namespace that has been granted pods/log read permission runs kubectl logs against the workflow-controller pod and finds the artifact repository credentials printed in plaintext in the logged configuration. Using those credentials, the attacker authenticates directly to the artifact repository (e.g. S3/MinIO/GCS bucket) and exfiltrates, modifies, or deletes stored artifacts. No public exploit code is required - only standard Kubernetes log access; no public exploit has been identified at time of analysis.