Argo Workflow may expose artifact repository credentials
An attacker who has permissions to read logs from pods in a namespace with Argo Workflow can read workflow-controller logs and get credentials to the artifact repository.
An attacker who has permissions to read logs from pods in a namespace with Argo Workflow can read workflow-controller logs and get credentials to the artifact repository.
Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. Versions prior to 3.6.12 and versions 3.7.0 through 3.7.2 contain a Zip Slip path traversal vulnerability in artifact extraction. During artifact extraction the unpack/untar logic (workflow/executor/executor.go) uses filepath.Join(dest, filepath.Clean(header.Name)) without validating that header.Name stays within the intended extraction directory. A malicious archive entry can supply a traversal or absolute path that, after cleaning, overrides the …
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}
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
Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. In affected versions an attacker can create a workflow which produces a HTML artifact containing an HTML file that contains a script which uses XHR calls to interact with the Argo Server API. The attacker emails the deep-link to the artifact to their victim. The victim opens the link, the script starts running. As the …
Impact This is pro-active fix. No know exploits exist. Impacted: You're running Kubernetes >= v1.19 You're running Argo Server It is configured to with –auth-mode=client Is not configured with –auth-mode=server You are not running Argo Server in Kubernetes pod. E.g. on bare metal or other VM. You're using client key to authenticate on the server. The server has more permissions that the connecting client's account. The client's authentication will be …
Impact We are not aware of any exploits. This is a pro-active fix. Impacted: You are running Argo Server < v3.0 with –secure=true or >= v3.0 with –secure unspecified (note - running in secure mode is recommended regardless). The attacker is within your network. If you expose Argo Server to the Internet then "your network" is "the Internet". The Argo Server's keys are packaged within the image. They could be …
In Argo Workflows through 3.1.3, if EXPRESSION_TEMPLATES is enabled and untrusted users are allowed to specify input parameters when running workflows, an attacker may be able to disrupt a workflow because expression template output is evaluated.