Argo CD Zero-Day: Unpatched Repo-Server RCE and Cluster Takeover Risks

We're implementing strict Kubernetes NetworkPolicies to deny ingress from anything other than the Argo CD API server and controller manager. It's a defense-in-depth approach. Even if an attacker gets into a different pod in the namespace, they shouldn't be able to reach the repo-server port directly.

Here is a basic snippet we are applying:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: repo-server-deny
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: argocd-repo-server
  policyTypes:
  - Ingress

This defaults to deny, and we whitelist specific IPs/services.

From a pentester's perspective, the 'internal port' requirement is the biggest danger for multi-tenant clusters. If an attacker compromises a single pod (perhaps via a vulnerable app), they can scan the cluster's internal CIDR. Finding port 8081 (default repo-server) open internally is game over for the cluster.

I'd suggest running an internal Nmap scan from a throwaway pod to see what's visible:

nmap -p 8081 10.0.0.0/8


If you can see it from a random pod, your segmentation isn't tight enough.

Since there's no CVE to feed into our scanners, I'm setting up custom alerts on unusual git clone activities originating from the repo-server logs. If the repo-server starts cloning repositories it doesn't usually touch, or if we see unexpected binary execution in the process tree, we're pulling the plug.

It's noisy, but better than a silent takeover.

Validating network isolation is just as important as defining the policies. In our environments, we schedule periodic checks from a 'canary' pod to verify the repo-server port isn't accidentally reachable. You can quickly test this reachability using netcat:

nc -zv argocd-repo-server 8081


If you receive a 'Connection refused' or timeout, you're good. Anything else means there's a leak in your segmentation. We also recommend limiting the repo-server's resources to prevent resource-exhaustion DoS attacks often used alongside RCE attempts.

To mitigate the impact if our network layers fail, we're scrutinizing the RBAC permissions assigned to the repo-server ServiceAccount. Least privilege is key here; the account shouldn't have rights to patch nodes or cluster roles.

I recommend checking effective permissions with this command to ensure the blast radius is contained:

kubectl auth can-i --list --as=system:serviceaccount:argocd:argocd-repo-server -n argocd

This gives you a clear view of what an attacker could actually do post-exploitation.

Building on the network isolation discussion, it's vital to audit existing Services for accidental exposure. Misconfigured LoadBalancers or NodePorts are the primary vector here. You can audit your cluster to ensure the repo-server Service is strictly ClusterIP with this command:

kubectl get svc -n argocd argocd-repo-server -o path='{.spec.type}'


If it returns anything other than `ClusterIP`, you need to reconfigure it immediately to prevent external access.