Argo Workflows (controller, daemon workflow SPDY client race): A data race in a global variable in the Kubernetes SPDY

Impact

A data race in a global variable in the Kubernetes SPDY client path lets any user who can run a workflow panic the workflow controller on demand. One tenant issuing back-to-back daemon workflows halts scheduling for every other tenant sharing that controller.

Who can reach it

Any principal with permission to execute a workflow in a namespace the controller watches. No elevated rights needed.

What to do

Upgrade the controller off 3.6.0-rc1 to 3.6.0-rc2 or any later release and restart. If you are running a release candidate in production, this is the signal to move to a GA build.

References

Related entries

• CRI-O: oversized /etc/passwd in a tenant image exhausts node memory when runAsUser is unknownCVE-2025-4437 · CRI-O (runAsUser resolution reads the container /etc/passwd into memory)Medium
• Docker Sandboxes: read-only host mounts stay writable at their virtio-fs shared-export pathCVE-2026-18171 · Docker Sandboxes (virtio-fs host-edge grant for read-only mounts)Medium
• Skipper routesrv: cluster-wide route and Redis/Valkey shard data served with no authenticationCVE-2026-54246 · Zalando Skipper routesrv (/routes and /swarm/*/shards endpoints)Medium
• Capsule: webhook rule typo lets a tenant user retag a namespace and cross tenant boundariesCVE-2026-55636 · Capsule (Kubernetes multi-tenancy) validating webhook rule for namespaces/finalizeMedium
• BuildKit: NTFS junctions inside the cache root escape the cache mount on Windows container workersCVE-2026-15788 · BuildKitMedium
• containerd: CRI checkpoint import does not validate image references in checkpoint metadataCVE-2026-50195 · containerdMedium