CVE-2024-53862
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.
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
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 Medium
CVSS: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 Medium
CVSS: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 Medium
CVSS: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 Medium
CVSS: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 High
CVSS: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 Medium
CVSS: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 Medium
CVSS: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
| Package | Affected | Fixed |
|---|---|---|
github.com/argoproj/argo-workflows/v3Go |
3.5.7 up to 3.5.13 | 3.5.13 |
github.com/argoproj/argo-workflows/v3Go |
3.6.0 up to 3.6.2 | 3.6.2 |
argo-workflowsBitnami |
3.5.7 up to 3.6.2 | 3.6.2 |
github.com/argoproj/argo-workflowsGo |
All versions | None known |
github.com/argoproj/argo-workflows/v2Go |
All versions | None known |
github.com/argoproj/argo-workflows/v3Go |
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/v3Root:Go |
before v3.6.0-root.io.2 | v3.6.0-root.io.2 |
github.com/argoproj/argo-workflows/v3Root:Go |
before v3.6.0-aikido.2 | v3.6.0-aikido.2 |
govulncheck-vulndbopenSUSE:Tumbleweed From an advisory covering 21 CVEs |
before 0.0.20241209T183251-1.1 | 0.0.20241209T183251-1.1 |
History
| Recorded | Changed | Sources |
|---|---|---|
| affected, facts | ||
| aliases, published | EUVD | |
| first indexed | CVE 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
github.com/argoproj/argo-workflows/security/advisories/GHSA-h36c-m3rf-34h9
github.com/argoproj/argo-workflows/pull/13021/files
nvd.nist.gov/vuln/detail/CVE-2024-53862
github.com/advisories/GHSA-h36c-m3rf-34h9
github.com/CVEProject/cvelistV5/tree/main/cves/2024/53xxx/CVE-2024-53862.json
github.com/argoproj/argo-workflows
Show 22 moreShow less
lists.opensuse.org/archives/list/[email protected]/thread/EK3MV2UFLDNRIXIWLVT5CJNSLB2MKFBU
suse.com/security/cve/CVE-2024-10220
suse.com/security/cve/CVE-2024-36620
suse.com/security/cve/CVE-2024-36621
suse.com/security/cve/CVE-2024-36623
suse.com/security/cve/CVE-2024-37820
suse.com/security/cve/CVE-2024-43784
suse.com/security/cve/CVE-2024-45719
suse.com/security/cve/CVE-2024-50948
suse.com/security/cve/CVE-2024-52003
suse.com/security/cve/CVE-2024-52529
suse.com/security/cve/CVE-2024-52801
suse.com/security/cve/CVE-2024-53259
suse.com/security/cve/CVE-2024-53264
suse.com/security/cve/CVE-2024-53858
suse.com/security/cve/CVE-2024-53862
suse.com/security/cve/CVE-2024-54131
suse.com/security/cve/CVE-2024-54132
suse.com/security/cve/CVE-2024-6156
suse.com/security/cve/CVE-2024-6219
suse.com/security/cve/CVE-2024-6538
suse.com/security/cve/CVE-2024-8676
Left out here: the rest of 2 source descriptions. The JSON record has them.