Every CVE Search/ Get API key

CVE-2024-53862

Argo Workflows Allows Access to Archived Workflows with Fake Token in `client` mode

6.3 MediumFix available

Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. When using --auth-mode=client, Archived Workflows can be retrieved with a fake or spoofed token via the GET Workflow endpoint: /api/v1/workflows/{namespace}/{name} or when using --auth-mode=sso, all Archived Workflows can be retrieved with a valid token via the GET Workflow endpoint: /api/v1/workflows/{namespace}/{name}. No authentication is performed by the Server itself on client tokens. Authentication & authorization is instead delegated to the k8s API server. However, the Workflow Archive does not interact with k8s, and so any token that looks valid will be considered authenticated, even if it is not a k8s token or even if the token has no RBAC for Argo. To handle the lack of pass-through k8s authN/authZ, the Workflow Archive specifically does the equivalent of a kubectl auth can-i check for respective methods. In 3.5.7 and 3.5.8, the auth check was accidentally removed on the GET Workflow endpoint's fallback to archived workflows on these lines, allowing archived workflows to be retrieved with a fake token. This vulnerability is fixed in 3.6.2 and 3.5.13.

Attack profile

How easy it is to exploit

Attack vector
Network
Complexity
Low
Privileges needed
None
User interaction
None

What an attacker can affect

Confidentiality
Low
Integrity
None
Availability
None

Exploit likelihood

0.66%Up 0.6 points since Dec 3, 2024
90%50%10%1%

What each source reports

CVE List Score used 6.3

Argo Workflows Allows Access to Archived Workflows with Fake Token in `client` mode

Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. When using --auth-mode=client, Archived Workflows can be retrieved with a fake or spoofed token via the GET Workflow endpoint: /api/v1/workflows/{namespace}/{name} or when using --auth-mode=sso, all Archived Workflows can be retrieved with a valid token via the GET Workflow endpoint: /api/v1/workflows/{namespace}/{name}. No authentication is performed by the Server itself on client tokens. Authentication & authorization is instead delegated to the k8s API server. However, the Workflow Archive does not interact with k8s, and so any token that looks valid will be considered authenticated, even if it is not a k8s token or even if the token has no RBAC for Argo. To handle the lack of pass-through k8s authN/authZ, the Workflow Archive specifically does the equivalent of a kubectl auth can-i check for respective methods. In 3.5.7 and 3.5.8, the auth check was accidentally removed on the GET Workflow endpoint's fallback to archived workflows on these lines, allowing archived workflows to be retrieved with a fake token. This vulnerability is fixed in 3.6.2 and 3.5.13.

Record
CVE-2024-53862
CVSS 4.0
6.3 MediumCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N
Weakness
CWE-200, CWE-290
Updated
2026-11-02
EUVDEUVD-2024-3475 6.3

Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. When using --auth-mode=client, Archived Workflows can be retrieved with a fake or spoofed token via the GET Workflow endpoint: /api/v1/workflows/{namespace}/{name} or when using --auth-mode=sso, all Archived Workflows can be retrieved with a valid token via the GET Workflow endpoint: /api/v1/workflows/{namespace}/{name}. No authentication is performed by the Server itself on client tokens. Authentication & authorization is instead delegated to the k8s API server. However, the Workflow Archive does not interact with k8s, and so any token that looks valid will be considered authenticated, even if it is not a k8s token or even if the token has no RBAC for Argo. To handle the lack of pass-through k8s authN/authZ, the Workflow Archive specifically does the equivalent of a kubectl auth can-i check for respective methods. In 3.5.7 and 3.5.8, the auth check was accidentally removed on the GET Workflow endpoint's fallback to archived workflows on these lines, allowing archived workflows to be retrieved with a fake token. This vulnerability is fixed in 3.6.2 and 3.5.13.

Record
EUVD-2024-3475
CVSS 4.0
6.3 MediumCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N
Updated
2026-11-03
GitHub AdvisoriesGHSA-h36c-m3rf-34h9 6.3

Access to Archived Argo Workflows with Fake Token in `client` mode

Summary

When using --auth-mode=client, Archived Workflows can be retrieved with a fake or spoofed token via the GET Workflow endpoint: /api/v1/workflows/{namespace}/{name}

When using --auth-mode=sso, all Archived Workflows can be retrieved with a valid token via the GET Workflow endpoint: /api/v1/workflows/{namespace}/{name}

Details

No authentication is performed by the Server itself on client tokens[^1]. Authentication & authorization is instead delegated to the k8s API server. However, the Workflow Archive does not interact with k8s, and so any token that looks valid will be considered authenticated, even if it is not a k8s token or even if the token has no RBAC for Argo. To handle the lack of pass-through k8s authN/authZ, the Workflow Archive specifically does the equivalent of a kubectl auth can-i check for respective methods.

In #12736 / v3.5.7 and #13021 / v3.5.8, the auth check was accidentally removed on the GET Workflow endpoint's fallback to archived workflows on these lines, allowing archived workflows to be retrieved with a fake token.

PoC

Configuration

Controller ConfigMap:

  config: |
    persistence:
      archive: true
      postgresql:
        database: argoworkflows
        host: db-host
        passwordSecret:
          key: postgresPassword
          name: argo-wf-postgres-credentials
        port: 5432
        tableName: argo_workflows
        userNameSecret:
          key: username
          name: argo-wf-postgres-credentials

Server: --auth-mode=client

Reproduction

Visit a completed, archived workflow URL with an invalid authorization token, this results in the workflow being displayed.

For example, directly query the API and retrieve the workflow data (where Bearer thisisatest is not a valid token):

curl -H 'Authorization: Bearer thisisatest' -v http://localhost:8000/api/v1/workflows/argo/hello-world-7tv5g

<details><summary>Results in a returned workflow:</summary>

* Host localhost:8000 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying [::1]:8000...
* Connected to localhost (::1) port 8000
> GET /api/v1/workflows/argo/hello-world-7tv5g HTTP/1.1
> Host: localhost:8000
> User-Agent: curl/8.7.1
> Accept: */*
> Authorization: Bearer thisisatest
>
* Request completely sent off
< HTTP/1.1 200 OK
< Content-Type: application/json
< Grpc-Metadata-Content-Type: application/grpc
< X-Ratelimit-Limit: 1000
< X-Ratelimit-Remaining: 999
< X-Ratelimit-Reset: Mon, 19 Aug 2024 20:44:27 UTC
< Date: Mon, 19 Aug 2024 20:44:26 GMT
< Transfer-Encoding: chunked
<
* Connection #0 to host localhost left intact
{
    "metadata": {
        "name": "hello-world-7tv5g",
        "generateName": "hello-world-",
        "namespace": "argo",
        "uid": "e5868ab1-f820-4a9e-9407-162346a4ccb4",
        "resourceVersion": "9982",
        "generation": 3,
        "creationTimestamp": "2024-08-13T23:59:20Z",
        "labels": {
            "workflows.argoproj.io/archive-strategy": "false",
            "workflows.argoproj.io/completed": "true",
            "workflows.argoproj.io/phase": "Succeeded",
            "workflows.argoproj.io/workflow-archiving-status": "Persisted"
        },
        "annotations": {
            "workflows.argoproj.io/description": "This is a simple hello world…
Record
GHSA-h36c-m3rf-34h9
CVSS 4.0
6.3 MediumCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N
Weakness
CWE-200
Updated
2026-11-02
NVD 6.3

Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. When using --auth-mode=client, Archived Workflows can be retrieved with a fake or spoofed token via the GET Workflow endpoint: /api/v1/workflows/{namespace}/{name} or when using --auth-mode=sso, all Archived Workflows can be retrieved with a valid token via the GET Workflow endpoint: /api/v1/workflows/{namespace}/{name}. No authentication is performed by the Server itself on client tokens. Authentication & authorization is instead delegated to the k8s API server. However, the Workflow Archive does not interact with k8s, and so any token that looks valid will be considered authenticated, even if it is not a k8s token or even if the token has no RBAC for Argo. To handle the lack of pass-through k8s authN/authZ, the Workflow Archive specifically does the equivalent of a kubectl auth can-i check for respective methods. In 3.5.7 and 3.5.8, the auth check was accidentally removed on the GET Workflow endpoint's fallback to archived workflows on these lines, allowing archived workflows to be retrieved with a fake token. This vulnerability is fixed in 3.6.2 and 3.5.13.

Record
CVE-2024-53862
CVSS 4.0
6.3 MediumCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Weakness
CWE-200, CWE-290
Updated
2026-11-02
OSV 6.3

Argo Workflows Allows Access to Archived Workflows with Fake Token in `client` mode

Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. When using --auth-mode=client, Archived Workflows can be retrieved with a fake or spoofed token via the GET Workflow endpoint: /api/v1/workflows/{namespace}/{name} or when using --auth-mode=sso, all Archived Workflows can be retrieved with a valid token via the GET Workflow endpoint: /api/v1/workflows/{namespace}/{name}. No authentication is performed by the Server itself on client tokens. Authentication & authorization is instead delegated to the k8s API server. However, the Workflow Archive does not interact with k8s, and so any token that looks valid will be considered authenticated, even if it is not a k8s token or even if the token has no RBAC for Argo. To handle the lack of pass-through k8s authN/authZ, the Workflow Archive specifically does the equivalent of a kubectl auth can-i check for respective methods. In 3.5.7 and 3.5.8, the auth check was accidentally removed on the GET Workflow endpoint's fallback to archived workflows on these lines, allowing archived workflows to be retrieved with a fake token. This vulnerability is fixed in 3.6.2 and 3.5.13.

Record
CVE-2024-53862
CVSS 4.0
6.3 MediumCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N
Weakness
CWE-200, CWE-290
Updated
2026-11-02
OSVGHSA-h36c-m3rf-34h9 6.3

Access to Archived Argo Workflows with Fake Token in `client` mode

Summary

When using --auth-mode=client, Archived Workflows can be retrieved with a fake or spoofed token via the GET Workflow endpoint: /api/v1/workflows/{namespace}/{name}

When using --auth-mode=sso, all Archived Workflows can be retrieved with a valid token via the GET Workflow endpoint: /api/v1/workflows/{namespace}/{name}

Details

No authentication is performed by the Server itself on client tokens[^1]. Authentication & authorization is instead delegated to the k8s API server. However, the Workflow Archive does not interact with k8s, and so any token that looks valid will be considered authenticated, even if it is not a k8s token or even if the token has no RBAC for Argo. To handle the lack of pass-through k8s authN/authZ, the Workflow Archive specifically does the equivalent of a kubectl auth can-i check for respective methods.

In #12736 / v3.5.7 and #13021 / v3.5.8, the auth check was accidentally removed on the GET Workflow endpoint's fallback to archived workflows on these lines, allowing archived workflows to be retrieved with a fake token.

PoC

Configuration

Controller ConfigMap:

  config: |
    persistence:
      archive: true
      postgresql:
        database: argoworkflows
        host: db-host
        passwordSecret:
          key: postgresPassword
          name: argo-wf-postgres-credentials
        port: 5432
        tableName: argo_workflows
        userNameSecret:
          key: username
          name: argo-wf-postgres-credentials

Server: --auth-mode=client

Reproduction

Visit a completed, archived workflow URL with an invalid authorization token, this results in the workflow being displayed.

For example, directly query the API and retrieve the workflow data (where Bearer thisisatest is not a valid token):

curl -H 'Authorization: Bearer thisisatest' -v http://localhost:8000/api/v1/workflows/argo/hello-world-7tv5g

<details><summary>Results in a returned workflow:</summary>

* Host localhost:8000 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying [::1]:8000...
* Connected to localhost (::1) port 8000
> GET /api/v1/workflows/argo/hello-world-7tv5g HTTP/1.1
> Host: localhost:8000
> User-Agent: curl/8.7.1
> Accept: */*
> Authorization: Bearer thisisatest
>
* Request completely sent off
< HTTP/1.1 200 OK
< Content-Type: application/json
< Grpc-Metadata-Content-Type: application/grpc
< X-Ratelimit-Limit: 1000
< X-Ratelimit-Remaining: 999
< X-Ratelimit-Reset: Mon, 19 Aug 2024 20:44:27 UTC
< Date: Mon, 19 Aug 2024 20:44:26 GMT
< Transfer-Encoding: chunked
<
* Connection #0 to host localhost left intact
{
    "metadata": {
        "name": "hello-world-7tv5g",
        "generateName": "hello-world-",
        "namespace": "argo",
        "uid": "e5868ab1-f820-4a9e-9407-162346a4ccb4",
        "resourceVersion": "9982",
        "generation": 3,
        "creationTimestamp": "2024-08-13T23:59:20Z",
        "labels": {
            "workflows.argoproj.io/archive-strategy": "false",
            "workflows.argoproj.io/completed": "true",
            "workflows.argoproj.io/phase": "Succeeded",
            "workflows.argoproj.io/workflow-archiving-status": "Persisted"
        },
        "annotations": {
            "workflows.argoproj.io/description": "This is a simple hello world…
Record
GHSA-h36c-m3rf-34h9
CVSS 4.0
6.3 MediumCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N
Weakness
CWE-200
Updated
2026-11-02
Show 4 moreShow less
OSVBIT-argo-workflows-2024-53862 No score

Argo Workflows Allows Access to Archived Workflows with Fake Token in `client` mode

Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. When using --auth-mode=client, Archived Workflows can be retrieved with a fake or spoofed token via the GET Workflow endpoint: /api/v1/workflows/{namespace}/{name} or when using --auth-mode=sso, all Archived Workflows can be retrieved with a valid token via the GET Workflow endpoint: /api/v1/workflows/{namespace}/{name}. No authentication is performed by the Server itself on client tokens. Authentication & authorization is instead delegated to the k8s API server. However, the Workflow Archive does not interact with k8s, and so any token that looks valid will be considered authenticated, even if it is not a k8s token or even if the token has no RBAC for Argo. To handle the lack of pass-through k8s authN/authZ, the Workflow Archive specifically does the equivalent of a kubectl auth can-i check for respective methods. In 3.5.7 and 3.5.8, the auth check was accidentally removed on the GET Workflow endpoint's fallback to archived workflows on these lines, allowing archived workflows to be retrieved with a fake token. This vulnerability is fixed in 3.6.2 and 3.5.13.

Record
BIT-argo-workflows-2024-53862
Updated
2026-11-02
OSVGO-2024-3303 No score

Argo Workflows Allows Access to Archived Workflows with Fake Token in `client` mode in github.com/argoproj/argo-workflows

Argo Workflows Allows Access to Archived Workflows with Fake Token in client mode in github.com/argoproj/argo-workflows

Record
GO-2024-3303
Updated
2026-11-02
OSVopenSUSE-SU-2024:14567-1 No score

govulncheck-vulndb-0.0.20241209T183251-1.1 on GA media

These are all security issues fixed in the govulncheck-vulndb-0.0.20241209T183251-1.1 package on the GA media of openSUSE Tumbleweed.

Record
openSUSE-SU-2024:14567-1
Updated
2026-11-02
OSVROOT-APP-GOBINARY-CVE-2024-53862 No score

CVE-2024-53862 in rootio-github.com/argoproj/argo-workflows/v3 - Patched by Root

Root has patched CVE-2024-53862 in the rootio-github.com/argoproj/argo-workflows/v3 package for Root:Go. Multiple fixed versions available.

Record
ROOT-APP-GOBINARY-CVE-2024-53862
Updated
2026-11-02

Affected products

Affected packages

Affected packages
PackageAffectedFixed
github.com/argoproj/argo-workflows/v3
Go
3.5.7 up to 3.5.13
3.5.13
github.com/argoproj/argo-workflows/v3
Go
3.6.0 up to 3.6.2
3.6.2
argo-workflows
Bitnami
3.5.7 up to 3.6.2
3.6.2
github.com/argoproj/argo-workflows
Go
All versions None known
github.com/argoproj/argo-workflows/v2
Go
All versions None known
github.com/argoproj/argo-workflows/v3
Go
3.5.7 up to 3.5.13, 3.6.0-rc1 up to 3.6.2
3.5.133.6.2
rootio-github.com/argoproj/argo-workflows/v3
Root:Go
before v3.6.0-root.io.2
v3.6.0-root.io.2
github.com/argoproj/argo-workflows/v3
Root:Go
before v3.6.0-aikido.2
v3.6.0-aikido.2
govulncheck-vulndb
openSUSE:Tumbleweed
From an advisory covering 21 CVEs
before 0.0.20241209T183251-1.1
0.0.20241209T183251-1.1

History

History
RecordedChangedSources
affected, facts
aliases, publishedEUVD
first indexedCVE List, GitHub Advisories, NVD, OSV

Dates are when Every CVE recorded each change. Upstream dates may differ.

In short

CVE-2024-53862 is a medium vulnerability (CVSS 6.3) in Argoproj Argo Workflows, published December 2, 2024. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.66%, the 51st percentile. Fixed in github.com/argoproj/argo-workflows/v3 3.5.13.

References

Show 22 moreShow less
This page doesn't list everything

Left out here: the rest of 2 source descriptions. The JSON record has them.

MoveEnter Open