Argo Workflows (Argo Server default --auth-mode=server before 3.0): Before 3.0 the Argo Server defaulted to

Impact

Before 3.0 the Argo Server defaulted to --auth-mode=server, meaning every request ran as the server's own service account. An exposed UI therefore lets anonymous internet users submit workflows that execute arbitrary containers on the cluster. This is the configuration behind the observed crypto-mining campaigns against Argo Workflows clusters.

Who can reach it

Any unauthenticated user who can reach the Argo Workflows UI, which in the reported incidents meant the open internet.

What to do

Move to --auth-mode=client and pull the UI off the internet immediately, then upgrade Argo Server to 3.x or later. Because this has been actively exploited in the wild, audit the cluster for unexpected workflows and workload pods before assuming it is clean.

References

Related entries

• Argo Workflows (Argo Server default --auth-mode=server before 3.0): Before 3.0 the Argo Server defaulted toNCVD-2021-020-argo-workflows-argo-server-defau · Argo Workflows (Argo Server default --auth-mode=server before 3.0)Unscored
• Argo Workflows (Argo Server, TLS keys baked into the container image): Argo Server's TLS private keys ship inside theNCVD-2021-018-argo-workflows-argo-server-tls-k · Argo Workflows (Argo Server, TLS keys baked into the container image)Unscored
• Argo Workflows (Argo Server, --auth-mode=client on Kubernetes 1.19+ outside a pod): In this configuration the client'sNCVD-2021-019-argo-workflows-argo-server-auth · Argo Workflows (Argo Server, --auth-mode=client on Kubernetes 1.19+ outside a pod)Unscored
• Argo CD: Unauthenticated attacker forges JWTs and gains full Argo CD admin, which in a GitOps clusterCVE-2022-29165 · Argo CDCritical
• Envoy: OAuth filter does not validate access tokens, so authentication can be skipped entirelyCVE-2022-29226 · EnvoyCritical
• BuildKit: "Leaky Vessels": RUN --mount empty-file removal can delete arbitrary host filesCVE-2024-23652 · BuildKitCritical