ArgoCD Vulnerable to Use of Risky or Missing Cryptographic Algorithms in Redis Cache

Summary

By default, the Redis database server is not password-protected. Consequently, an attacker with access to the Redis server can gain read/write access to the data in Redis. The attacker can also modify the "mfst" (manifest) key to cause ArgoCD to execute any deployment, potentially leveraging ArgoCD's high privileges to take over the cluster. Updating the "cacheEntryHash" in the manifest JSON is necessary, but since it doesn't use a private key for signing its integrity, a simple script can generate a new FNV64a hash matching the new manifest values. The repo-server, unable to verify if its cache is compromised, will read the altered "mfst" key and initiate an update process for the injected deployment.

It's also possible to edit the "app|resources-tree" key, causing the ArgoCD server to load any Kubernetes resource into the live manifest section of the app preview. This could lead to an information leak.

The fact that the cache in Redis is neither signed nor validated, combined with Redis's default lack of password protection, presents a significant security concern given ArgoCD's high-level permissions within the cluster. A security update should ensure all Redis database values are signed or encrypted.

Details

We began by deploying ArgoCD on an EKS cluster. Surprisingly, we discovered that an unprivileged pod in a different namespace on the same cluster could connect to the Redis server on port 6379. This was unexpected, as we had observed network policy…