Argo CD is a leading open-source GitOps tool that lets you manage your Kubernetes resources by tracking them in Git. If you run modern infrastructure, especially on Kubernetes, chances are you use or at least know about Argo CD.

But recently, a major security flaw was found in Argo CD—CVE-2024-31990—that let attackers change Kubernetes resources using the Argo CD user interface, bypassing important security settings meant to protect your cluster. This vulnerability has been fixed, but understanding how it worked is critical for anyone using Argo CD.

What Exactly Is CVE-2024-31990?

CVE-2024-31990 is a flaw in how the Argo CD API server checks security settings for projects. Specifically, it does not properly enforce the sourceNamespaces restriction on a project when users operate via the web UI.

The bottom line:
Attackers could modify Kubernetes resources in namespaces that should have been protected—resources that were supposed to be controlled only via changes in GitOps, not by someone clicking in the UI.

Understanding the Risk

In Argo CD, admins can define "Projects." Each project can restrict which resources it manages, including:

What Kubernetes clusters and namespaces resources can be created in (destinations)

- *What namespaces can serve as sources for Application manifests (sourceNamespaces)* (this is the part with the bug)

This setup is supposed to prevent anyone from using Argo CD’s UI to sneakily deploy or edit resources outside of intended areas.

The bug:
The API server failed to actually check the sourceNamespaces restriction when updating resources through the UI. That means if you restricted a project to use only manifests from, say, the "production" namespace, it could actually update resources from any namespace anyway—*if you used the UI instead of GitOps*.

Exploit Scenario: How Would an Attacker Use This?

Suppose you set up Argo CD to keep critical Kubernetes resources locked down, only to be updated through your GitOps pipeline. If someone gets "Edit" access to Argo CD:

Because the API doesn’t check sourceNamespaces as it should, their change goes through.

4. Now they’ve tampered with resources that could control networking, secrets, or even access to your cluster.

Imagine your project is defined like this in Argo CD

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: secure-project
spec:
  sourceNamespaces:
    - production
  destinations:
    - namespace: production
      server: https://kubernetes.default.svc
  sourceRepos:
    - https://github.com/example/repo.git

This *should* restrict source manifests so they're only taken from the production namespace.

But with CVE-2024-31990...

A user with access to the UI could still create an "Application" that points to a manifest in, say, the dev namespace. They’d use the UI to either create or edit the app, picking dev as the namespace. Argo CD would not stop them—even though that’s supposed to be blocked.

Quick Exploit PoC (Proof of Concept)

Suppose you’re an attacker with access to the Argo CD UI. Here’s a demonstration of how you’d bypass restriction:

1. Log into the Argo CD UI with “Edit” rights to a project having sourceNamespaces restrictions.

Save and sync the application.

No error, no rejection—you just got away with it!

Patch your deployment as soon as possible.

# For example, if you use Helm to manage Argo CD:
helm repo update
helm upgrade argocd argo/argo-cd --version 2.10.7

Or use your normal deployment method—just make sure you’re on one of the fixed releases.

2. Review Your Access Controls

Make sure only trusted users have edit access to Argo CD. Remember, the exploit requires UI access, so “least privilege” goes a long way.

3. Audit for Unauthorized Changes

Check your Kubernetes audit logs and Argo CD logs for edits or application syncs coming from unexpected namespaces.

References

- Original Argo CD security advisory
- GitHub Issue #14007
- Official fix PRs

Summary

CVE-2024-31990 shows that even with powerful GitOps tools like Argo CD, you can never trust software to be perfect—especially when it comes to enforcing security boundaries.

The take-home message:

Stay alert.

If you rely on Argo CD for critical infrastructure, patching to the latest version is a no-brainer.

Stay safe and keep your clusters locked down!

*Have additional questions about securing Argo CD or other Kubernetes GitOps tools? Feel free to ask in the comments!*

Timeline

Published on: 04/15/2024 20:15:11 UTC
Last modified on: 06/04/2024 17:35:59 UTC