CVE-2025-62157: Argo Workflows Credential Disclosure Flaw

CVE-2025-62157 Overview

CVE-2025-62157 is a credential exposure vulnerability in Argo Workflows, an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. The workflow-controller writes its full configuration, including artifact repository credentials, to pod logs in plaintext. Any user with permission to read pod logs in the namespace running Argo Workflows can retrieve these credentials and access the connected artifact repository. The flaw affects versions prior to 3.6.12 and versions 3.7.0 through 3.7.2, and is tracked under [CWE-522: Insufficiently Protected Credentials].

Critical Impact
An authenticated Kubernetes user with pod log read permissions in the Argo Workflows namespace can extract artifact repository credentials and pivot to the backing storage system.

Affected Products

Argoproj Argo Workflows versions prior to 3.6.12
Argoproj Argo Workflows versions 3.7.0 through 3.7.2
Kubernetes clusters running the affected workflow-controller component

Discovery Timeline

2025-10-14 - CVE-2025-62157 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-62157

Vulnerability Analysis

The WorkflowController.updateConfig() function marshals the controller's full configuration object into YAML and writes it to the pod log at INFO level on every configuration update. The configuration structure includes the ArtifactRepository block, which holds credentials such as S3 access keys, secret keys, and equivalent tokens for other backends. Because the controller logs the marshaled bytes verbatim, these secrets appear in cleartext inside standard container logs. The vulnerability falls under the [CWE-522] category of insufficiently protected credentials.

Root Cause

The root cause is unsafe logging of a sensitive configuration structure. The controller treated the artifact repository credentials the same as any other configuration field and did not redact them before serialization. Kubernetes pod logs are typically readable by users with get/list on the pods/log subresource in the namespace, expanding the effective trust boundary of those credentials to every log reader.

Attack Vector

Exploitation requires a Kubernetes principal with permission to read pod logs in the namespace running the workflow-controller. The attacker runs kubectl logs against the controller pod, greps for the Configuration: banner, and extracts the artifact repository access key and secret. Those credentials can then be used against the configured S3, GCS, Azure Blob, or Artifactory endpoint to read, modify, or destroy workflow artifacts.

// Patched code from workflow/controller/config.go
func (wfc *WorkflowController) updateConfig(ctx context.Context) error {
-	bytes, err := yaml.Marshal(wfc.Config)
+	_, err := yaml.Marshal(wfc.Config)
 	if err != nil {
 		return err
 	}
-	log.Info("Configuration:\n" + string(bytes))
+	log.Info("Configuration updated")
 	wfc.artifactRepositories = artifactrepositories.New(wfc.kubeclientset, wfc.namespace, &wfc.Config.ArtifactRepository)
}
// Source: https://github.com/argoproj/argo-workflows/commit/bded09fe4abd37cb98d7fc81b4c14a6f5034e9ab

The patch stops marshaling the config into a logged string and replaces the verbose banner with a static Configuration updated message, eliminating credential leakage from controller output.

Detection Methods for CVE-2025-62157

Indicators of Compromise

Historical workflow-controller pod logs containing the string Configuration: followed by a YAML block that includes artifactRepository, accessKeySecret, or secretKeySecret fields.
Unexpected kubectl logs or Kubernetes API pods/log requests targeting the workflow-controller pod from non-administrative service accounts or users.
Artifact repository access log entries showing use of the leaked access key from source IPs outside the cluster egress range.

Detection Strategies

Query centralized log storage for the literal token Configuration:\n emitted by pre-patch workflow-controller pods, and treat any match as a credential exposure event.
Audit Kubernetes API server logs for get and list verbs on pods/log scoped to the Argo Workflows namespace, grouped by subject and correlated with role bindings.
Enable object storage audit logging (for example, AWS CloudTrail S3 data events) and alert on access to workflow artifact buckets from principals or IP addresses not associated with the cluster.

Monitoring Recommendations

Continuously monitor Argo Workflows controller pod versions and flag any instance running below 3.6.12 or in the 3.7.0–3.7.2 range.
Track RBAC changes that grant pods/log read permission in namespaces hosting Argo Workflows and require change-management review.
Rotate and alert on artifact repository credentials proactively, and monitor for reuse of retired keys against the storage backend.

How to Mitigate CVE-2025-62157

Immediate Actions Required

Upgrade Argo Workflows to version 3.6.12 or 3.7.3 in every affected cluster before performing credential rotation, so the new secret is not immediately re-logged.
Rotate all artifact repository credentials referenced by the workflow-controller configuration, including S3, GCS, Azure, and Artifactory keys.
Purge historical workflow-controller pod logs from container runtimes and centralized logging systems, and revoke any snapshots or backups that contain the leaked configuration block.
Review RBAC role bindings in the Argo Workflows namespace and remove pods/log access from principals that do not require it.

Patch Information

The fix is delivered in Argo Workflows 3.6.12 and 3.7.3. The relevant upstream commits are 18ad5138 and bded09fe, which remove the YAML marshaling of the controller configuration from the info log. Full details are published in the GitHub Security Advisory GHSA-c2hv-4pfj-mm2r.

Workarounds

No official workarounds exist per the vendor advisory; upgrading to a patched version is required.
As an interim compensating control, restrict pods/log permissions in the Argo Workflows namespace to a minimal set of administrative service accounts.
Consider isolating the workflow-controller in a dedicated namespace with tightly scoped RBAC until patched versions can be deployed cluster-wide.

bash

# Upgrade Argo Workflows via Helm to a patched version
helm repo update
helm upgrade argo-workflows argo/argo-workflows \
  --namespace argo \
  --version 3.7.3

# Verify the running controller version
kubectl -n argo get deploy workflow-controller \
  -o jsonpath='{.spec.template.spec.containers[0].image}'

# Restrict pods/log access in the Argo namespace
kubectl -n argo get rolebindings,clusterrolebindings -o wide \
  | grep -Ei 'pods/log|view|edit'