GPU VulnDB

Database/Container, Kubernetes & orchestration

Argo CD: unauthenticated Bitbucket webhook payload crashes the API server into CrashLoopBackOff

CVSS 7.5CVE-2025-59531Container, Kubernetes & orchestrationcurated

Impact

A single unauthenticated HTTP request to Argo CD's /api/webhook endpoint, carrying a Bitbucket Server payload whose repository.links.clone field is not an array, panics and kills the whole argocd-server process. Because the endpoint is reachable without a configured webhook.bitbucketserver.secret (the default), one request puts the pod into CrashLoopBackOff, and repeating it against each replica takes the entire Argo CD API down. For a GPU fleet that deploys GPU Operator, device plugins, scheduler configs and model-serving manifests through GitOps, that means no syncs, no rollbacks and no emergency config pushes until Argo CD is back. Confidentiality and integrity are unaffected - this is availability only.

Who can reach it

Anyone who can reach the argocd-server HTTP endpoint. No authentication and no webhook secret needed; if the Argo CD server is exposed beyond the cluster or to tenant networks, the request comes from anywhere on that path.

What to do

Upgrade to Argo CD 2.14.20, 3.0.19, 3.1.8 or 3.2.0-rc2 and restart argocd-server - a control-plane deployment restart, no node drain and no GPU workload impact. As an interim mitigation, set webhook.bitbucketserver.secret so unsigned payloads are rejected, and keep /api/webhook off any network the workloads can reach.

References

Related entries

All Container, Kubernetes & orchestration entries

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.