IL-0065 Cycode · 2024-01-18kubernetessecurity
Argo CD keeps a cache in Redis to reduce calls to the Kubernetes API and the Git provider. In the default installation that Redis had no password and any pod in the cluster could reach it unless a network policy stopped it. The cache holds application manifests and, when users commit manifests with secrets or plugins generate manifests with secrets, those secrets as well.
Each cached manifest carries a cacheEntryHash that the repo server uses to detect changes: when Cycode first edited a manifest, the repo server restored the original. The hash, however, is an fnv64a checksum computed without any secret key. Cycode recomputed it for an altered manifest, and at its next comparison the application controller found the application out of sync and deployed the altered version. As proof of concept they deployed a privileged pod that mounted the host file system and added their SSH key to the node. The report says the same path gives access to Kubernetes Secrets and allows removing the evidence.
The vulnerability is CVE-2024-31989 with a score of 9.1. Cycode reported it through GitHub Security Advisories on 18 January 2024; Argo CD confirmed it on 25 January, created the CVE on 9 April and on 21 May 2024 released 2.11.1, 2.10.10, 2.9.15 and 2.8.19, which initialize a password for Redis. The report calls this a partial fix: connecting without prior information is no longer possible.
This is a vulnerability report, not an outage, so nothing failed visibly. What an engineer can check is whether the Argo CD Redis server accepts connections without a password from a pod in another namespace, on port 6379 at the address kube-dns returns. In the default installation it did.
Its keys hold gzip-compressed cached data about the applications Argo CD manages, including their manifests, under names such as `mfst|app.kubernetes.io/instance|myapp|42…|1.8.3.gz`. Whether other pods can reach it depends on the NetworkPolicy checked with `kubectl -n argocd get networkpolicy argocd-redis-network-policy`, and on a CNI that actually enforces network policies.
Root cause ? Software defect
Found by Cycode Labs security research, not by an operator.
–
The hash that checks the cached manifests is computed without a secret key, so anyone who can write to Redis can recompute it and make Argo CD deploy an altered manifest. Cycode recommends upgrading to the fixed versions, checking that the argocd-redis-network-policy NetworkPolicy exists and that a CNI enforces it, using controller-based secret management instead of injecting secrets through Argo CD plugins so secrets never reach Redis, and running Argo CD on a dedicated cluster.
same root cause · shared Argo CD