CVE-2024-31990

Executive Summary

CVE-2024-31990 is a medium-severity vulnerability in Argo CD, a popular GitOps continuous delivery tool for Kubernetes. The flaw resides in the API server's failure to enforce project sourceNamespaces restrictions. This allows an authenticated attacker with low privileges to use the Argo CD UI to edit resources that should only be mutable via GitOps workflows. The vulnerability effectively bypasses the intended security boundary that separates UI-based management from GitOps-driven reconciliation. While the CVSS score is 4.8 (Medium), the impact is significant in environments where strict separation of duties and namespace isolation is required. No public exploit code or proof-of-concept is currently available, and the EPSS score is 0.0%, indicating low active exploitation in the wild.

Supply Chain & Package Security

Argo CD is a Go-based application distributed as a container image and a Kubernetes-native deployment. The vulnerability is not in a package dependency but in the application logic itself. Organizations using Argo CD should prioritize patching to prevent unauthorized configuration drift.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:H/A:N
• Base Score: 4.8 (Medium)
• Attack Vector: Network (AV:N) – The vulnerability is exploitable over the network.
• Attack Complexity: Low (AC:L) – No special conditions are required.
• Privileges Required: Low (PR:L) – An attacker needs a valid Argo CD account with limited permissions.
• User Interaction: Required (UI:R) – The attacker must trick a user with higher privileges or use their own session to perform the action.
• Scope: Unchanged (S:U) – The vulnerable component and the impacted component are the same.
• Confidentiality Impact: None (C:N) – No data exposure.
• Integrity Impact: High (I:H) – Unauthorized modification of resources is possible.
• Availability Impact: None (A:N) – No denial of service.

Threat Level: Medium. The requirement for user interaction and low privileges reduces the immediate risk, but the integrity impact is high in environments where GitOps is the sole source of truth.

Deep Dive & Mechanics

Argo CD uses the concept of "projects" to group applications and enforce policies. Each project can define sourceNamespaces – a list of Kubernetes namespaces from which applications are allowed to be created or managed. This is intended to prevent users from creating applications in unauthorized namespaces.

The vulnerability arises because the API server does not properly validate the sourceNamespaces constraint when handling UI-based requests. When a user with low privileges (e.g., a project role that should only allow GitOps-based changes) uses the UI to edit an application, the API server fails to check whether the target namespace is within the allowed sourceNamespaces list. This allows the attacker to modify application resources (e.g., change the Git repository URL, sync policy, or even the application's namespace) that should only be mutable via Git commits.

The root cause is a missing authorization check in the API handler for UI-based resource updates. The code path for UI edits bypasses the project validation logic that is enforced for GitOps-driven changes.

Vulnerable vs. Patched Code

The vulnerability is in the API server's resource update handler. In vulnerable versions, the handler does not call the project validation function for UI-based requests.

Vulnerable Code (simplified):

func (s *Server) UpdateResource(ctx context.Context, req *UpdateResourceRequest) (*ResourceResponse, error) {
    // Missing: project validation for sourceNamespaces
    // Directly proceeds to update the resource
    return s.updateResource(ctx, req)
}

Patched Code (simplified):

func (s *Server) UpdateResource(ctx context.Context, req *UpdateResourceRequest) (*ResourceResponse, error) {
    // Added: project validation for sourceNamespaces
    if err := s.validateProjectSourceNamespaces(ctx, req); err != nil {
        return nil, err
    }
    return s.updateResource(ctx, req)
}

The patch adds a call to validateProjectSourceNamespaces which checks that the target namespace is within the allowed list for the project. This ensures that UI-based edits are subject to the same restrictions as GitOps-based changes.

Exploitation & Lab Setup

Red Team

Prerequisites:

• Access to an Argo CD instance with a low-privilege user account (e.g., a project role with get and update permissions on applications).
• The target application must be in a namespace that is NOT in the project's sourceNamespaces list.

Exploitation Steps:

1. Authenticate to the Argo CD UI with the low-privilege account.
2. Navigate to the target application.
3. Use the UI to edit the application (e.g., change the spec.source.repoURL to a malicious repository).
4. Save the changes. The API server will accept the update without validating the namespace.
5. The application will sync from the malicious repository, potentially deploying unauthorized resources.

No public exploit code is available. The attack is purely UI-based and does not require custom scripts.

Blue Team

Detection:

• Monitor Argo CD audit logs for UpdateResource API calls from UI sessions that originate from users with low privileges.
• Alert on any changes to application spec.source.repoURL or spec.destination.namespace that are not preceded by a Git commit.
• Use the following Suricata rule to detect anomalous API requests.

Mitigation:

• Immediately upgrade to Argo CD 2.10.7, 2.9.12, or 2.8.16.
• As a workaround, restrict UI access to only trusted users and enforce strict RBAC policies.
• Enable audit logging and monitor for unauthorized changes.

Indicators of Compromise (IOCs)

• Log Entries: Argo CD API server logs showing UpdateResource requests from UI sessions with low-privilege users.
• Network Traffic: HTTP POST requests to /api/v1/applications/{name}/resource with a JSON body containing changes to spec.source or spec.destination.
• Kubernetes Events: Unusual changes to Application CRDs that are not reflected in the Git repository.
• User Agent: Requests from the Argo CD UI typically have a user agent like ArgoCD-UI/v2.x.x.

Detection Engineering

YARA Rule

rule CVE_2024_31990_ArgoCD_UI_Edit {
    meta:
        description = "Detects Argo CD UI-based resource edit requests that bypass sourceNamespaces validation"
        author = "Valters IT"
        date = "2024-10-27"
        reference = "CVE-2024-31990"
        hash = "N/A"
    strings:
        $api_path = "/api/v1/applications/" ascii wide nocase
        $resource_update = "resource" ascii wide nocase
        $ui_session = "ArgoCD-UI" ascii wide nocase
    condition:
        $api_path and $resource_update and $ui_session
}

Sigma Rule

title: Argo CD UI-Based Resource Edit Without GitOps Validation
id: 8a9b3c2d-1e5f-4a7b-8c9d-0e1f2a3b4c5d
status: experimental
description: Detects HTTP requests to Argo CD API that indicate a UI-based resource edit which may bypass sourceNamespaces validation (CVE-2024-31990)
author: Valters IT
date: 2024-10-27
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-31990
logsource:
    category: webserver
    product: argo-cd
detection:
    selection:
        cs-method: 'POST'
        cs-uri-stem|contains: '/api/v1/applications/'
        cs-uri-stem|endswith: '/resource'
        cs-user-agent|contains: 'ArgoCD-UI'
    condition: selection
falsepositives:
    - Legitimate UI edits by authorized users
level: medium
tags:
    - attack.t1190
    - cve.2024.31990

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CVE-2024-31990 - Argo CD UI Resource Edit Bypass";
    flow:to_server,established;
    content:"POST";
    http_method;
    content:"/api/v1/applications/";
    http_uri;
    content:"/resource";
    http_uri;
    content:"ArgoCD-UI";
    http_user_agent;
    sid:10000001;
    rev:1;
    reference:cve,2024-31990;
    classtype:attempted-admin;
    priority:2;
)

Remediation & Mitigation

Immediate Actions:

1. Patch: Upgrade Argo CD to version 2.10.7, 2.9.12, or 2.8.16 (or later). Follow the official upgrade guide at https://argo-cd.readthedocs.io/en/stable/operator-manual/upgrading/.
2. Workaround: If patching is not immediately possible, restrict UI access to only trusted administrators. Use RBAC to limit who can edit applications via the UI.
3. Audit: Review recent audit logs for any unauthorized changes to application resources.

Long-Term Measures:

• Implement strict GitOps-only workflows where all changes must be made via Git commits.
• Use Argo CD's built-in project validation features (e.g., sourceNamespaces, destinationNamespaces) and ensure they are enforced.
• Regularly review and update RBAC policies to follow the principle of least privilege.
• Enable and monitor audit logs for suspicious API calls.

Valters IT Signature

Report generated by Valters IT DevSecOps Intelligence Unit. For questions, contact security@valters.it.