argoproj argo-workflows up to 3.5.12/3.6.1 GET Workflow Endpoint {name} information disclosure

Summaryinfo

A vulnerability, which was classified as problematic, has been found in argoproj argo-workflows up to 3.5.12/3.6.1. This affects an unknown part of the file /api/v1/workflows/{namespace}/{name} of the component GET Workflow Endpoint. This manipulation causes information disclosure. This vulnerability is handled as CVE-2024-53862. The attack can be initiated remotely. There is not any exploit available. It is advisable to upgrade the affected component.

Detailsinfo

A vulnerability classified as problematic was found in argoproj argo-workflows up to 3.5.12/3.6.1. Affected by this vulnerability is an unknown functionality of the file /api/v1/workflows/{namespace}/{name} of the component GET Workflow Endpoint. The manipulation with an unknown input leads to a information disclosure vulnerability. The CWE definition for the vulnerability is CWE-200. The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information. As an impact it is known to affect confidentiality. The summary by CVE is:

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.

It is possible to read the advisory at github.com. This vulnerability is known as CVE-2024-53862 since 11/22/2024. The exploitation appears to be easy. The attack can be launched remotely. The exploitation doesn't need any form of authentication. Technical details of the vulnerability are known, but there is no available exploit. The attack technique deployed by this issue is T1592 according to MITRE ATT&CK.

Upgrading to version 3.5.13 or 3.6.2 eliminates this vulnerability. Applying a patch is able to eliminate this problem. The bugfix is ready for download at github.com. The best possible mitigation is suggested to be upgrading to the latest version.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Productinfo

Vendor

• argoproj

Name

• argo-workflows

Version

• 3.5.0
• 3.5.1
• 3.5.2
• 3.5.3
• 3.5.4
• 3.5.5
• 3.5.6
• 3.5.7
• 3.5.8
• 3.5.9
• 3.5.10
• 3.5.11
• 3.5.12
• 3.6.0
• 3.6.1

Website

• Product: https://github.com/argoproj/argo-workflows/

CPE 2.3info

• 🔍
• 🔍
• 🔍

CPE 2.2info

• 🔍
• 🔍
• 🔍

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Discussion