Argo Workflows (Argo Server, archived workflow retrieval under client/sso auth mode): With --auth-mode=client the

Impact

With --auth-mode=client the archived-workflow GET endpoint accepts a forged token, and with --auth-mode=sso any valid token reads any archived workflow regardless of namespace. An attacker or a low-privilege tenant reads other tenants' completed run history - parameters, artifact locations, and whatever those specs embed.

Who can reach it

Anyone who can reach the Argo Server API. In client mode a fabricated token is enough; in SSO mode any legitimate account, including the lowest-privilege one, reads everything.

What to do

Upgrade Argo Server to 3.5.13 or 3.6.2 and restart. Prefer --auth-mode=server or sso with the fix in place over client mode, and treat archived workflow contents as having been readable by every authenticated user before the upgrade.

References

Related entries

• Kubernetes Image Builder: Default credentials present during the build window for several providersCVE-2024-9594 · Kubernetes Image BuilderMedium
• containerd: Unbounded read on OCI image import causes containerd OOMCVE-2023-25153 · containerdMedium
• Kubernetes (kubelet): Unauthenticated node DoS through the kubelet checkpoint API filling node diskCVE-2025-0426 · Kubernetes (kubelet)Medium
• Calico: DeleteCollection skips AuthorizeTierOperation, so a tenant can delete tiered NetworkPolicies theyCVE-2026-41187 · CalicoMedium
• containerd: "ContainerDrip": registry credentials leaked to an attacker-controlled URL referenced in an image manifestCVE-2020-15157 · containerdMedium
• runc: AppArmor bypass when /proc inside the container is symlinked with a specific mount configCVE-2023-28642 · runcMedium