CVE-2022-24730

Executive Summary

CVE-2022-24730 is a path traversal vulnerability compounded by an improper access control flaw in Argo CD, a declarative GitOps continuous delivery tool for Kubernetes. Affected versions include Argo CD 1.3.0 through 2.1.10, 2.2.0 through 2.2.5, and pre-2.3.0 releases, allowing a malicious user with read-only repository get access to leak sensitive files from the repo-server process. The vulnerability carries a CVSS score of 7.7 (High) and exposes files from other applications' source repositories plus any secrets mounted as files on the repo-server, though exploitation requires the attacker to know or guess target file paths.

Technical Analysis

Argo CD's repo-server component is responsible for cloning, rendering, and caching manifests from Git repositories and Helm charts. The vulnerability exists in the application details endpoint (/api/v1/repositories/{repo_url}/appdetails), which is used to retrieve metadata about a Helm chart stored in a repository. Two distinct flaws compound to create the exposure:

Path Traversal Flaw: When processing a request to the appdetails endpoint, the server fails to properly validate or normalize file paths within the repository context. A crafted payload that references a file using directory traversal sequences (e.g., ../../) can cause the repo-server to read files outside the intended repository directory. The server does not appear to implement adequate canonicalization or containment checks to ensure all accessed paths remain within the root of the requested repository.

Improper Access Control Flaw: The access control logic for the appdetails endpoint incorrectly assumes that a user with get (read-only) access to a repository is authorized to request application details from that repository. The authorization check does not account for the fact that a read-only repository user may be able to escape the repository context via the path traversal flaw. Access is not restricted to users with Application create privileges, nor is it limited to cases where the repo_url has already been associated with an Application the user can access. This lack of context-aware authorization creates a privilege boundary violation.

The NVD description explicitly identifies the exploitable endpoint but does not provide function names, class names, or code-level implementation details. The vulnerability class is cross-file read via path traversal; the data exfiltration channel is the HTTP response body. For non-YAML file contents, the data is returned as part of an error message, indicating that error handling routines echo back file content to the requester without adequate sanitization.

Attackers must know or guess the absolute path or relative path of the target file on the repo-server filesystem. Successful exploitation leaks the complete contents of targeted files back to the attacker over the API response channel.

Exploitation Scenarios

The attack chain for CVE-2022-24730 is inferred from the vulnerability class and the explicit endpoint information in the NVD description. No public PoC is available at the time of writing; the chain below is derived from the described mechanics.

Step 1 — Reconnaissance and Target Identification: The attacker must authenticate to the Argo CD API and hold a role that grants get (read) access to at least one repository that contains a Helm chart. This is a low-privilege position achievable by any legitimate read-only user of an Argo CD instance. The attacker identifies the target Argo CD server URL and the repo_url of a repository for which they have get access. The target files of interest are typically secrets mounted as files on the repo-server (e.g., Kubernetes secrets volume-mounted into the repo-server pod) or source files from other applications (e.g., .git configuration, deployment keys, TLS certificates).

Step 2 — Flaw Class Trigger: The attacker constructs an HTTPS request to the appdetails endpoint, using a path traversal sequence in the payload to escape the repository root. Because the NVD description does not reveal the exact parameter name, the attack is described at the class level: the request includes a reference to an out-of-bounds file, and the server processes this reference without adequate canonicalization.

Step 3 — Payload/Execution Method: The attacker crafts the API request to the /api/v1/repositories/{repo_url}/appdetails endpoint with a malicious payload substituting the legitimate Helm chart path for a traversal sequence that resolves to a sensitive file outside the repository. The server reads the file and returns its content in the HTTP response. If the file is non-YAML, the response returns an error message containing the file contents, making data exfiltration possible even for binary or non-structured files.

Step 4 — Post-Exploitation Impact: Sensitive file contents exfiltrated include:

• Files from other Applications' source repositories (e.g., deployment configurations, private keys, API tokens)
• Any secrets mounted as files on the repo-server (e.g., Kubernetes secret volumes)
• Configuration files containing credentials for external systems the repo-server integrates with

The attacker can repeat the process for multiple file paths, systematically harvesting secrets. Exfiltrated credentials may enable lateral movement into CI/CD systems, source code repositories, or production Kubernetes clusters.

Impact Assessment

Confidentiality Impact: High. Attackers with low-privilege read-only access can exfiltrate arbitrary files from the repo-server filesystem, including secrets mounted as files and source code from other applications. The CVSS confidentiality subscore is rated High (C:H in the vector), reflecting direct and complete loss of file confidentiality.

Integrity Impact: None. The vulnerability is purely a disclosure flaw; there is no mechanism for file modification or deletion described. The I:N component of the CVSS vector confirms no integrity impact.

Availability Impact: None. Exploitation does not disrupt service availability per the CVSS vector (A:N).

CVSS Analysis: The base score of 7.7 is derived from AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N — Network attack vector, Low attack complexity, Low privileges required, No user interaction, Unchanged scope, High confidentiality impact. The low privilege requirement is significant: any read-only repository user, potentially including external audit or guest accounts, can escalate to arbitrary file disclosure.

Blast Radius: The repo-server runs as a pod in the Argo CD installation. All mounted secrets (e.g., TLS certificates, deployment keys used for git repositories, cloud provider credentials) are exposed. Additionally, any source repository material cached on the repo-server's filesystem for other applications is at risk. In multi-tenant Argo CD deployments where multiple teams share a single instance, tenant isolation is completely broken.

Detection Guidance

Sigma Rule

title: Argo CD Path Traversal attempt via appdetails endpoint
id: 7f4d2c1e-9a3b-4c8d-8e1f-3a2b6c7d9e0a
status: experimental
description: Detects path traversal patterns in requests to Argo CD appdetails endpoint
author: Valtersit Threat Intel
date: 2025/01/01
logsource:
  category: webserver
  product: argo-cd
  service: argocd-server
detection:
  selection_endpoint:
    cs-uri-query|contains: '/api/v1/repositories/'
    cs-uri-query|contains: '/appdetails'
  selection_traversal:
    cs-uri-query|contains:
      - '..%2f'
      - '..%5c'
      - '%2e%2e%2f'
      - '%2e%2e%5c'
      - '/../'
      - '/etc/'
      - '/proc/'
  condition: selection_endpoint and selection_traversal
level: high
falsepositives:
  - Legitimate configuration referencing files outside repo root (rare)
fields:
  - src_ip
  - c-uri
  - user_agent

YARA Rule

rule ArgoCD_PathTraversal_Appdetails
{
    meta:
        author = "Valtersit Threat Intel"
        description = "Detects path traversal patterns in Argo CD appdetails API requests"
        date = "2025-01-01"
        score = 70
        cve = "CVE-2022-24730"
    strings:
        $endpoint = "/api/v1/repositories/" ascii nocase
        $appdetails = "/appdetails" ascii nocase
        $dotdot_slash = "/../" ascii
        $dotdot_encoded = "%2e%2e%2f" ascii nocase
        $backslash_dotdot = "..\\" ascii
        $dotdot_encoded_lower = "%2e%2e%5c" ascii nocase
        $etc_passwd = "/etc/passwd" ascii
        $etc_shadow = "/etc/shadow" ascii
        $proc_self = "/proc/self" ascii
    condition:
        $endpoint and $appdetails and any of ($dotdot*)
        or ($endpoint and $appdetails and any of ($etc*))
        or ($endpoint and $appdetails and any of ($proc*))
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2022-24730 Argo CD Path Traversal via appdetails endpoint"; flow:to_server,established; http.uri; content:"/api/v1/repositories/"; content:"/appdetails"; distance:0; pcre:"/(%2e%2e[/\\]*(%2e%2e[/\\]*)+|\.\.[/\\]+\.\.[/\\])+/i"; classtype:attempted-user; reference:cve,2022-24730; reference:url,https://nvd.nist.gov/vuln/detail/CVE-2022-24730; sid:20224730; rev:1;)

Elastic Detection

sequence by source.ip with maxspan=5m
  [ network where process.name == "argocd-server" and
      outcome == "success" and
      url.path like "*api*repositories*appdetails*" and
      (url.path like "*..%2f*" or url.path like "*..%5c*" or url.path like "*..\\*" or url.path like "*../*") ]
  [ file where process.name == "argocd-server" and file.operation == "open" and
      (file.path == "/etc/*" or file.path == "/proc/*" or file.path like "*..*") ]

Splunk SPL Query

index=webserver sourcetype=access_combined
| where uri LIKE "%/api/v1/repositories/%/appdetails%"
| search uri IN ("*..%2f*", "*..%5c*", "*%2e%2e%2f*", "*%2e%2e%5c*", "*../*", "*..\\*")
  OR uri IN ("*/etc/*", "*/proc/*", "*/var/run/secrets/*")
| table _time, src_ip, user, uri, status, response_time
| sort _time desc

Wazuh OSSEC Rule

<group name="argo-cd,">
  <rule id="498249" level="12">
    <decoded_as>json</decoded_as>
    <field name="url">\.\/api\/v1\/repositories\/.\+\/appdetails</field>
    <regex>\.\.%2f|\.\.%5c|%2e%2e%2f|%2e%2e%5c|\.\.\/|\.\.\\</regex>
    <description>Argo CD path traversal attempt detected on appdetails endpoint (CVE-2022-24730)</description>
    <group>attack.path_traversal,</group>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch Confidence Note: The CVE data indicates patch confidence 0/4 with no patch evidence from tracked sources. Despite the NVD description explicitly stating that versions 2.1.11, 2.2.6, and 2.3.0 contain patches, the tracked patch evidence does not confirm this. Organizations should verify the patch status with the vendor directly and apply the described fixed versions after validation.

1) Immediate Mitigations (in order of priority):

• Restrict network access to the Argo CD API and repo-server to trusted networks and VPN users only.
• Audit all repository access grants; revoke get access for any users who do not require repository read access. Consider that any read-only repo user is a potential exploiter.
• Apply the Kubernetes NetworkPolicy to restrict ingress to the repo-server pod to only the argocd-server component; the repo-server should never be directly reachable from external networks.
• Monitor API logs for anomalous appdetails requests containing traversal patterns (use the detection rules above for automated alerting).
• Run Argo CD with minimal secrets mounted on the repo-server; review all volume mounts and Secret references on the repo-server Deployment manifest and remove non-essential ones.

2) Patch/Upgrade Steps:

• Upgrade Argo CD to version 2.1.11, 2.2.6, 2.3.0, or later per the vendor patch statement. For deployments on versions ≥ 2.3.0, ensure the version is current with all subsequent security releases.
• The patches prevent path traversal and limit access to users with either Application create privileges or users with Application get privileges where the repo_url has already been used for the given Application.
• After upgrading, verify that the appdetails endpoint rejects traversal payloads by sending a test request with an encoded traversal sequence and confirming the server returns a 400/403 error without file contents.

3) Long-Term Hardening:

• Implement least-privilege access for Argo CD: separate repository get access from Application management privileges. Ensure no role grants repository get without also being scoped to specific applications.
• Run the repo-server with only the minimum secrets and credentials required for its function. Store secrets in external secret management (Vault, cloud secret managers) and access them at runtime rather than mounting files.
• Conduct a secrets audit: rotate all credentials and keys that may have been exposed on the repo-server filesystem.
• Enable Argo CD audit logging and integrate with SIEM/SOAR for automated response to anomalous API patterns.
• Subscribe to Argo CD security advisories and prioritize patching cycles to avoid prolonged exposure windows.

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2022-24730 (NVD description and CVSS data)
2. Argo CD Security Advisories: https://github.com/argoproj/argo-cd/security/advisories (Vendor advisory and patch references)
3. CVE-2022-24730 on MITRE: https://www.cve.org/CVERecord?id=CVE-2022-24730
4. EPSS Data: https://www.first.org/epss/ (EPSS score 0.00881, 55.8% percentile)
5. CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog (CVE not listed in KEV — no known in-the-wild exploitation evidence)

Threat Actor Intelligence Note: This CVE is not listed on the CISA Known Exploited Vulnerabilities (KEV) list, and there is no publicly documented evidence of nation-state or organized criminal exploitation campaigns targeting this vulnerability. The EPSS score of 0.00881 (55.8% percentile) indicates a low but non-zero probability of exploitation in the wild; the vulnerability remains a viable target for low-and-slow exfiltration attempts by authorized users with modest technical capability. No exploit code is publicly available at the time of writing.