Database/Container, Kubernetes & orchestration
Argo Workflows (Argo Server, --auth-mode=client on Kubernetes >= 1.19): PRIVILEGE ESCALATION TO THE SERVER'S IDENTITY
Impact
PRIVILEGE ESCALATION TO THE SERVER'S IDENTITY: in a specific configuration the client's authentication is silently ignored and the server's own credentials are used instead, so every caller gets whatever the Argo Server account can do. The conditions are narrow — Kubernetes 1.19 or newer, Argo Server running outside a Kubernetes pod (bare metal or a VM), --auth-mode=client without --auth-mode=server, clients authenticating with a client key, and the server holding more permissions than the connecting account. But the reason this matters to an operator is that it inverts the intended posture: client mode is what you switch to in order to make callers act as themselves, so the deployment that took the hardening step is the one that silently loses it. The maintainers describe it as a proactive fix with no known exploits.
Who can reach it
Network, low privileges: any client that can authenticate to an Argo Server running off-cluster in the configuration above. The escalation happens automatically rather than requiring a crafted request.
What to do
Upgrade Argo Workflows to a release carrying the fix and restart the server. Prefer running Argo Server inside a Kubernetes pod, which takes the affected configuration off the table. Where it must run off-cluster, keep the server's own service account scoped no wider than the least-privileged caller you accept, so an ignored client identity does not hand out more than the caller already had.
References
Related entries
- netavark: container name resolution falls through to host search domains and reaches external serversCVE-2025-8283 · netavark (Podman/CRI-O container DNS resolution)Low
- cosign / sigstore: Expired issuing certificate treated as valid during verificationCVE-2026-24122 · cosign / sigstoreLow
- runc: runc can be tricked into creating empty files/directories at arbitrary host locationsCVE-2024-45310 · runcLow
- ECK operator: credentials survive an RBAC-denied cross-namespace association, keeping tenant read accessCVE-2026-78600 · Elastic Cloud on Kubernetes operator (cross-namespace association credentials)Low
- Kubernetes (kubelet): Pods with an empty localhost seccomp profile field silently bypass seccomp enforcementCVE-2023-2431 · Kubernetes (kubelet)Low
- cosign / sigstore: Cosign can be tricked into claiming a Rekor transparency-log entry exists when it does notCVE-2022-23649 · cosign / sigstoreLow
This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.