Argo-Workflows — CraftedSignal Threat Feed

Argo Workflows Credentials Exposed in Pod Logs

hello@craftedsignal.io — Mon, 04 May 2026 20:12:01 +0000

Argo Workflows, a Kubernetes-native workflow engine, is vulnerable to credential exposure. Specifically, versions 4.0.0 through 4.0.4 inadvertently log artifact repository credentials in plaintext during artifact operations. This includes sensitive data like S3 Access Keys, Secret Keys, Session Tokens, Server-Side Customer Keys, OSS Access Keys, Secret Keys, Security Tokens, and GCS Service Account Keys. The vulnerability stems from the logging driver passing the entire ArtifactDriver struct to the structured logger. Any user with read access to workflow pod logs can extract these credentials, creating a significant security risk. This is an incomplete fix of CVE-2025-62157.

Attack Chain

An attacker gains read access to Kubernetes pod logs within the Argo Workflows namespace. This could be achieved through compromised credentials, misconfigured RBAC policies, or other Kubernetes vulnerabilities.
The attacker identifies a workflow that utilizes artifact storage, such as S3 or GCS.
The workflow executes an artifact operation (upload or download).
Argo Workflows logs the entire ArtifactDriver struct, including the plaintext credentials, into the pod logs.
The attacker queries the pod logs using kubectl or other Kubernetes tooling. For example: kubectl -n argo logs "cred-leak-test" -c wait.
The attacker extracts the plaintext credentials (e.g., S3 Access Key and Secret Key) from the log output.
The attacker uses the extracted credentials to access the artifact repository (e.g., S3 bucket) and potentially steal data or perform other unauthorized actions.

Impact

Successful exploitation of this vulnerability allows unauthorized access to artifact repositories used by Argo Workflows. This can lead to data breaches, as sensitive data stored in S3 buckets, GCS buckets, or other storage solutions can be exposed. The impact is especially severe if the compromised credentials have broad permissions or if the artifact repository contains highly sensitive data. This affects Argo Workflows versions 4.0.0, 4.0.1, 4.0.2, 4.0.3, and 4.0.4.

Recommendation

Upgrade Argo Workflows to version 4.0.5 or later to remediate the vulnerability (CVE-2026-42295).
Review and restrict Kubernetes RBAC permissions to limit access to pod logs, following the principle of least privilege.
Implement log monitoring and alerting for unusual access patterns to Kubernetes pod logs.
Rotate any potentially exposed artifact repository credentials (S3 access keys, GCS service account keys, etc.) if Argo Workflows versions 4.0.0-4.0.4 were in use.

Argo Workflows Template Referencing Restriction Bypass

hello@craftedsignal.io — Mon, 04 May 2026 20:11:38 +0000

Argo Workflows, a Kubernetes-native workflow engine, contains an incomplete fix for CVE-2026-31892. The initial patch blocked podSpecPatch modifications when templateReferencing: Strict was active. However, other fields within the WorkflowSpec that influence pod creation, such as hostNetwork, serviceAccountName, and securityContext, were not restricted. This allows a malicious user to bypass intended security controls and potentially escalate privileges within the Kubernetes cluster. Versions affected include those supporting the templateReferencing feature, specifically v4.0.2 and v3.7.11, which include the initial fix for CVE-2026-31892 but are still vulnerable to this bypass. This vulnerability exists because the check in setExecWorkflow only validates HasPodSpecPatch(), while other critical fields are applied directly to the pod specification. The bypass affects both Strict and Secure modes.

Attack Chain

Attacker gains create Workflow permission within the Argo Workflows environment.
Attacker crafts a Workflow manifest that references a hardened WorkflowTemplate.
Attacker sets hostNetwork: true (or other vulnerable fields like securityContext, serviceAccountName, tolerations, or automountServiceAccountToken) in the Workflow manifest.
The Workflow is submitted, and the setExecWorkflow function in the Argo controller only checks for podSpecPatch.
Due to the missing validation, the user-defined hostNetwork: true (or other vulnerable fields) is merged with the WorkflowTemplate specification.
The createWorkflowPod function reads the merged specification and applies the hostNetwork: true setting directly to the pod specification, bypassing the intended restrictions.
A pod is created with host networking enabled, granting the container access to the host’s network namespace.
The attacker can now access sensitive information or perform actions on the network as if they were running directly on the host.

Impact

Successful exploitation allows an attacker to bypass the intended security restrictions imposed by Argo Workflows’ templateReferencing feature. This can lead to privilege escalation, unauthorized access to network resources, and the potential to compromise other containers or nodes within the Kubernetes cluster. The impact is most significant in clusters that rely on Argo’s Strict mode as the primary enforcement layer, as other Kubernetes-level controls like PodSecurity admission or OPA/Gatekeeper may not be in place to mitigate these bypasses.

Recommendation

Deploy the Sigma rule Argo Workflow Host Network Bypass to detect workflows attempting to set hostNetwork: true, and tune for your environment.
Deploy the Sigma rule Argo Workflow Service Account Override to detect workflows attempting to override the service account.
Upgrade to a patched version of Argo Workflows that addresses CVE-2026-42296, ensuring that all WorkflowSpec fields that influence pod security posture are validated.
Implement Kubernetes-level controls, such as PodSecurity admission or OPA/Gatekeeper, to provide an additional layer of defense against unauthorized pod specification modifications.

Argo Workflows Controller Denial-of-Service via Malformed Pod Annotation

hello@craftedsignal.io — Thu, 23 Apr 2026 21:39:21 +0000

Argo Workflows is vulnerable to a denial-of-service attack where a malformed workflows.argoproj.io/pod-gc-strategy annotation within a workflow pod can crash the Argo Workflows controller. This vulnerability stems from an unchecked array index in the podGCFromPod() function. When the annotation value lacks a “/”, the strings.Split function returns an array of length 1, leading to an out-of-bounds access when trying to retrieve the second element. The resulting panic occurs outside the controller’s recovery scope, causing the entire controller process to terminate. The affected versions include 3.6.5 through 3.6.19, 3.7.0-rc1 through 3.7.12, and 4.0.0-rc1 through 4.0.3. This vulnerability was introduced in commit #14129.

Attack Chain

An attacker crafts a malicious Argo Workflow YAML file.
The YAML includes a podMetadata section defining annotations for the workflow pod.
Within the annotations, the workflows.argoproj.io/pod-gc-strategy key is set to a value that does not contain a forward slash ("/"), such as “NoSlash”.
The attacker submits the crafted workflow to the Argo Workflows controller using kubectl apply -n argo -f malicious-workflow.yaml.
The Argo Workflows controller receives the workflow definition and creates a corresponding pod based on the specification.
The podGCFromPod() function in /workflow/controller/pod/controller.go attempts to parse the workflows.argoproj.io/pod-gc-strategy annotation.
The strings.Split function splits the annotation value, resulting in an array with only one element.
The code attempts to access parts[1], causing a panic due to an out-of-bounds array access and crashes the controller, resulting in a denial-of-service.

Impact

Successful exploitation of this vulnerability allows any user with the ability to submit workflows to crash the Argo Workflows controller. The controller will enter a crash loop, rendering the entire Argo Workflows deployment unavailable. Since the controller is responsible for managing and executing workflows, all workflow processing is halted, leading to a denial-of-service condition. This can severely impact organizations relying on Argo Workflows for their CI/CD pipelines or other automated tasks. The attacker requires only create permission on Workflow resources to execute this attack.

Recommendation

Upgrade to a patched version of Argo Workflows (v3.6.4 or earlier, v3.6.20+, v3.7.13+, or v4.0.4+) to remediate the vulnerability as described in GHSA-5jv8-h7qh-rf5p.
Implement input validation on workflow submissions to reject workflows with malformed workflows.argoproj.io/pod-gc-strategy annotations. See the PoC workflow example provided in GHSA-5jv8-h7qh-rf5p for examples of vulnerable annotation values.
Deploy the Sigma rule Detect Argo Workflows Malformed Pod GC Annotation to detect workflow submissions containing potentially malicious annotations.

Argo Workflows ConfigMap Sync Service Missing Authorization Vulnerability

hello@craftedsignal.io — Fri, 03 May 2024 16:23:00 +0000

Argo Workflows, a Kubernetes-native workflow engine, is vulnerable to an authorization bypass in its Sync Service’s ConfigMap-backed provider. This vulnerability, present in versions 4.0.0 through 4.0.4, stems from a lack of authorization checks on CRUD operations performed on ConfigMaps. This means that any authenticated user, even with a fake Bearer token, can create, read, update, and delete Kubernetes ConfigMaps used for synchronization limits. This flaw allows attackers to potentially disrupt workflow execution, access sensitive configuration data, or even manipulate ConfigMaps in namespaces accessible to the server’s service account. The vulnerability was reported on May 4, 2026, and poses a significant risk to Argo Workflows deployments.

Attack Chain

Attacker gains network access to the Argo Server.
Attacker authenticates to the Argo Server using any valid or even a “fake” Bearer token (e.g., fake-token).
Attacker crafts a POST request to the /api/v1/sync/default endpoint to create a new Sync Limit ConfigMap with specified parameters like namespace, ConfigMap name, key, and limit.
The Argo Server’s configMapSyncProvider.createSyncLimit function executes without performing any authorization checks.
The function uses the Kubernetes client to create a ConfigMap in the specified namespace based on the attacker’s input.
Attacker can subsequently send GET, PUT, or DELETE requests to /api/v1/sync/default/{key} to read, update, or delete existing Sync Limit ConfigMaps without authorization.
The Argo Server processes these requests, modifying the ConfigMaps accordingly, due to the missing auth.CanI checks.
The attacker disrupts workflow execution, gains access to sensitive configuration data, or manipulates ConfigMaps, leading to denial of service or other malicious outcomes.

Impact

Successful exploitation of this vulnerability allows an attacker with network access to the Argo Server and valid or fake authentication credentials to perform several malicious actions. They can cause a denial of service by setting sync limits to zero or a very low number, effectively blocking parallel workflow execution. Attackers can also disrupt running workflows by modifying existing sync limits. Furthermore, they can gain access to sensitive information by reading ConfigMap data or manipulate ConfigMaps in any namespace accessible to the server’s service account. This could lead to complete compromise of the Argo Workflows environment.

Recommendation

Upgrade to Argo Workflows version 4.0.5 or later to patch CVE-2026-42297 and mitigate the missing authorization checks.
Monitor access logs on the Argo Server for unexpected API calls to the /api/v1/sync endpoints, especially POST, PUT, and DELETE requests, which could indicate unauthorized ConfigMap manipulation. Use the rule Argo Workflows ConfigMap Sync Service Modification to detect unauthorized modifications.
Implement network segmentation and access controls to limit network access to the Argo Server, reducing the attack surface.