CVE-2024-47827: Argo Workflows Controller Denial of Service Vulnerability

MODERATE
Advisory Identifier: GHSA-ghjw-32xw-ffwr
CVSS 5.7
CWE-362 CWE-1108
Published
Advisory Summary

CVE-2024-47827 is a MODERATE (CVSS 5.7) denial of service vulnerability (CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')) affecting Argo Workflows Controller libraries in the Go ecosystem. The issue involves denial of service via malicious daemon workflows. Remediation is available by upgrading affected packages to version 3.6.0-rc2.

CVE-2024-47827 at a Glance

CVE Identifier CVE-2024-47827
GHSA Identifier GHSA-ghjw-32xw-ffwr
Severity MODERATE
CVSS v3.1 Base Score 5.7
CWE Classification CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Affected Product Argo Workflows Controller
Package Ecosystem Go
Published Date
Last Updated

Security Impact

CVSS: 5.7

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).

Attack Vector Adjacent (AV:A)
Attack Complexity Low (AC:L)
Privileges Required Low (PR:L)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality None (C:N)
Integrity None (I:N)
Availability High (A:H)

How to Fix CVE-2024-47827

To remediate this vulnerability, upgrade all affected Argo Workflows Controller dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

github.com/argoproj/argo-workflows/v3 fixed: 3.6.0-rc2
Upgrade github.com/argoproj/argo-workflows/v3 to 3.6.0-rc2
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for github.com/argoproj/argo-workflows/v3

How to Check if You Are Affected

To determine whether your application is affected by CVE-2024-47827, inspect your project dependencies for Argo Workflows Controller:

inspect dependencies for github.com/argoproj/argo-workflows/v3

Analyze the terminal output to locate any version of Argo Workflows Controller in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 3.6.0-rc2), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'), where the product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently. In Argo Workflows Controller, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### Summary Due to a race condition in a global variable, the argo workflows controller can be made to crash on-command by any user with access to execute a workflow. This was resolved by https://github.com/argoproj/argo-workflows/pull/13641 ### Details These two lines introduce a data race in the underlying SPDY implementation of the Kubernetes API client. If a second request is made before the first completes, it results in a panic due to a null pointer. * https://github.com/argoproj/argo-workflows/blob/ce7f9bfb9b45f009b3e85fabe5e6410de23c7c5f/workflow/metrics/metrics_k8s_request.go#L49 * https://github.com/argoproj/argo-workflows/blob/ce7f9bfb9b45f009b3e85fabe5e6410de23c7c5f/workflow/metrics/metrics_k8s_request.go#L75 This appears to have been added in this commit https://github.com/argoproj/argo-workflows/commit/9756babd0ed589d1cd24592f05725f748f74130b / #13265 / v3.6.0-rc1 ### PoC With the `KUBECONFIG` variable set to an appropriate file with `create` permissions for the `Workflow` kind, execute the following bash script: ```bash #!/bin/bash -xeu while true ; do name=$( { argo submit /dev/stdin <<'EOF' apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: generateName: curl- spec: entrypoint: main templates: - name: main dag: tasks: - name: no-op template: no-op withSequence: count: 3 - name: no-op daemon: true container: image: alpine:3.13 command: [sleep, infinity] EOF } | head -n1 | awk '{ print $2 }' ) ( sleep 30; argo terminate $name ) & sleep 15 done ``` This script creates, and subsequently cleans up, multiple `daemon` pods in rapid succession. Each pod cleanup involves executing a `kill` instruction using the Kubernetes `exec` API, triggering the conditions for the panic. This can be seen when the tests mark the pods as complete, but the workflow itself never completes. Observing the controller logs when this happens shows the panic and restart of the controller every few seconds. In a setup with exponential backoff (e.g. a Kubernetes Pod) this is enough to reliably cause crashes enough to extend this backoff significantly and leave other workflows stalled. Because the restarted controller believes it has sent the `kill` signal, it will wait indefinitely for the pod to terminate, which it never will, so the attack must constantly garbage-collect its own workflows with the `argo terminate` command, otherwise the maximum concurrently running workflows will be reached. A more sophisticated attack could detect when the workflow has been signaled to clean up and terminate it then instead of relying on a simple timer. ### Impact A malicious user with access to create workflows can continually submit workflows that do nothing except create and then clean up multiple daemon pods, resulting in a crash-loop that prevents other users' workflows from running. This can be done with only a handful of pods and very little cpu and memory, meaning typical multi-tenant Kubernetes controls such as Pod count and resource quotas are not effective at preventing it. Because the panic log does not in any way suggest that the issue has anything to do with the daemon pods, and an attacker could easily disguise these daemon pods as part of a genuine workflow, it would be difficult for administrators to discover the root cause of the DoS and the individuals responsible to remove their access.

CVE-2024-47827 Affected Argo Workflows Controller Versions

1 component(s)
Fixed Versions:
3.6.0-rc2
Product / Package Ecosystem Affected Versions Fixed Version
github.com/argoproj/argo-workflows/v3
Go
≥ 3.6.0-rc1
< 3.6.0-rc2
All 1 versions
3.6.0-rc1
3.6.0-rc2

References

Frequently Asked Questions

What is CVE-2024-47827?
CVE-2024-47827 is a security vulnerability in Argo Workflows Controller involving Denial of Service via malicious daemon Workflows under CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition').
Which Argo Workflows Controller versions are affected?
Affected versions include releases prior to 3.6.0-rc2 across affected packages: github.com/argoproj/argo-workflows/v3.
What version fixes CVE-2024-47827?
Upgrading to 3.6.0-rc2 (or the latest patched release for your respective branch) resolves the vulnerability.
Is github.com/argoproj/argo-workflows/v3 affected?
Yes, github.com/argoproj/argo-workflows/v3 is affected in releases prior to 3.6.0-rc2. Upgrade your dependency to 3.6.0-rc2 or later.
What is the CVSS score of CVE-2024-47827?
CVE-2024-47827 has a CVSS v3.1 base score of 5.7 (MODERATE) with vector string CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H.
What CWE is associated with CVE-2024-47827?
CVE-2024-47827 is classified under CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') (The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.).
How can I check Go dependencies for CVE-2024-47827?
Run the dependency tree command: 'inspect dependencies for github.com/argoproj/argo-workflows/v3'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-ghjw-32xw-ffwr",
  "modified" : "2026-02-06T21:31:12Z",
  "published" : "2024-10-28T18:28:03Z",
  "aliases" : [ "CVE-2024-47827" ],
  "summary" : "Argo Workflows Controller: Denial of Service via malicious daemon Workflows",
  "details" : "### Summary\n\nDue to a race condition in a global variable, the argo workflows controller can be made to crash on-command by any user with access to execute a workflow.\n\nThis was resolved by https://github.com/argoproj/argo-workflows/pull/13641\n\n### Details\n\nThese two lines introduce a data race in the underlying SPDY implementation of the Kubernetes API client. If a second request is made before the first completes, it results in a panic due to a null pointer.\n* https://github.com/argoproj/argo-workflows/blob/ce7f9bfb9b45f009b3e85fabe5e6410de23c7c5f/workflow/metrics/metrics_k8s_request.go#L49\n* https://github.com/argoproj/argo-workflows/blob/ce7f9bfb9b45f009b3e85fabe5e6410de23c7c5f/workflow/metrics/metrics_k8s_request.go#L75\n\nThis appears to have been added in this commit https://github.com/argoproj/argo-workflows/commit/9756babd0ed589d1cd24592f05725f748f74130b / #13265 / v3.6.0-rc1\n\n### PoC\n\nWith the `KUBECONFIG` variable set to an appropriate file with `create` permissions for the `Workflow` kind, execute the following bash script:\n\n```bash\n#!/bin/bash -xeu\n\nwhile true ; do\n    name=$(\n        { argo submit /dev/stdin <<'EOF'\napiVersion: argoproj.io/v1alpha1\nkind: Workflow\nmetadata:\n  generateName: curl-\nspec:\n  entrypoint: main\n  templates:\n  - name: main\n    dag:\n      tasks:\n        - name: no-op\n          template: no-op\n          withSequence:\n            count: 3\n  - name: no-op\n    daemon: true\n    container:\n      image: alpine:3.13\n      command: [sleep, infinity]\nEOF\n    } | head -n1 | awk '{ print $2 }'\n    )\n    ( sleep 30; argo terminate $name ) &\n    sleep 15\ndone\n```\n\nThis script creates, and subsequently cleans up, multiple `daemon` pods in rapid succession. Each pod cleanup involves executing a `kill` instruction using the Kubernetes `exec` API, triggering the conditions for the panic. This can be seen when the tests mark the pods as complete, but the workflow itself never completes. Observing the controller logs when this happens shows the panic and restart of the controller every few seconds. In a setup with exponential backoff (e.g. a Kubernetes Pod) this is enough to reliably cause crashes enough to extend this backoff significantly and leave other workflows stalled.\n\nBecause the restarted controller believes it has sent the `kill` signal, it will wait indefinitely for the pod to terminate, which it never will, so the attack must constantly garbage-collect its own workflows with the `argo terminate` command, otherwise the maximum concurrently running workflows will be reached. A more sophisticated attack could detect when the workflow has been signaled to clean up and terminate it then instead of relying on a simple timer.\n\n### Impact\n\nA malicious user with access to create workflows can continually submit workflows that do nothing except create and then clean up multiple daemon pods, resulting in a crash-loop that prevents other users' workflows from running. This can be done with only a handful of pods and very little cpu and memory, meaning typical multi-tenant Kubernetes controls such as Pod count and resource quotas are not effective at preventing it.\n\nBecause the panic log does not in any way suggest that the issue has anything to do with the daemon pods, and an attacker could easily disguise these daemon pods as part of a genuine workflow, it would be difficult for administrators to discover the root cause of the DoS and the individuals responsible to remove their access.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"
  }, {
    "type" : "CVSS_V4",
    "score" : "CVSS:4.0/AV:A/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Go",
      "name" : "github.com/argoproj/argo-workflows/v3"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "3.6.0-rc1"
      }, {
        "fixed" : "3.6.0-rc2"
      } ]
    } ],
    "versions" : [ "3.6.0-rc1" ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/argoproj/argo-workflows/security/advisories/GHSA-ghjw-32xw-ffwr"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2024-47827"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/argoproj/argo-workflows/pull/13641"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/argoproj/argo-workflows/commit/524406451f4dfa57bf3371fb85becdb56a2b309a"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/argoproj/argo-workflows"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/argoproj/argo-workflows/blob/ce7f9bfb9b45f009b3e85fabe5e6410de23c7c5f/workflow/metrics/metrics_k8s_request.go#L75"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-1108", "CWE-362" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2024-10-28T18:28:03Z",
    "nvd_published_at" : "2024-10-28T16:15:03Z"
  }
}