CVE-2022-31034

Executive Summary

CVE-2022-31034 is a cryptographic weakness in Argo CD, a declarative GitOps continuous delivery tool for Kubernetes, affecting all versions from v0.11.0 up to the fixed releases. The vulnerability stems from the use of a non-cryptographically-secure pseudo-random number generator (PRNG) seeded with a relatively predictable time-based value in OAuth2/OIDC login flows initiated from the Argo CD CLI or UI. This insufficient entropy in OAuth2/OIDC parameters (e.g., state and PKCE parameters) weakens login-flow protections, making it theoretically possible for an attacker to craft login-flow attacks such as login CSRF, session fixation, or account takeover. While the attack is difficult to execute in practice, successful exploitation could grant an attacker admin access to an Argo CD instance, which in turn provides full control over deployed Kubernetes workloads. The issue is patched in Argo CD versions v2.4.1, v2.3.5, v2.2.10, and v2.1.16.

Technical Analysis

Argo CD uses OAuth2/OIDC flows to authenticate users through external identity providers (e.g., Dex, GitHub, Okta). These flows rely on several parameters that must be unpredictable and unique per request to prevent cross-site request forgery (CSRF), replay, and session-fixation attacks:

• state parameter: used to mitigate CSRF by maintaining a session token between the client and the authorization server.
• PKCE code_verifier / code_challenge: used to bind the authorization code exchange to the original client, preventing authorization code interception/replay.
• nonce (OIDC): used to associate a client session with an ID token, preventing token replay.

Per RFC 6749 (OAuth 2.0), RFC 7636 (PKCE), and OpenID Connect Core 1.0, these parameters MUST be generated using a secure random source with sufficient entropy. The NVD description states that Argo CD used a "relatively-predictable (time-based) seed in a non-cryptographically-secure pseudo-random number generator" — likely a language-standard PRNG (e.g., math/rand in Go) seeded with time.Now().UnixNano() or a similar low-entropy source. In some cases the parameters were also too short, further diminishing entropy.

The attack surface is the public-facing login endpoint of Argo CD (typically /auth/login or the CLI's login command, e.g., argocd login). When a legitimate user initiates SSO login, a malicious actor who can predict or observe the generation timing can:

1. Predict the state or PKCE values by correlating timestamps with PRNG output sequences.
2. Pre-emptively start a login request with a crafted state (login CSRF) to trick the user into authenticating in the attacker's session context.
3. Intercept/modify the authorization code exchange if PKCE code_verifier is predictable, allowing authorization code interception.

The NVD description notes the attacks are "difficult to accomplish" — likely requiring either network-level observation (to time the PRNG generation) or a local/close position to the target, or multiple login attempts to establish a timing oracle. However, the impact is severe: if an attacker can control the OAuth login flow parameters, they may be able to associate their session with admin privileges, leading to full administrative control over Argo CD and the connected Kubernetes cluster. No specific function names, file paths, or exact parameter names are disclosed beyond the generic OAuth2/OIDC parameters.

Exploitation Scenarios

Stage 1 — Target Identification and Reconnaissance.
An attacker scans for exposed Argo CD instances, typically on ports 8080 (HTTP) or 8443 (HTTPS), or via Shodan/Censys queries for the default Argo CD web UI. They identify the login mechanism (SSO/OIDC configured) by observing the login page or calling the CLI login endpoint. The attacker also identifies the Argo CD version by checking the web UI footer or API responses (e.g., /api/v1/version) to confirm the instance is within the affected range.

Stage 2 — Triggering the Vulnerability Class.
The attacker monitors the network or observes the Argo CD server-side timing. Since the PRNG seed is time-based, the attacker needs to correlate the exact server timestamp with the PRNG output. They can do this by initiating their own login requests to measure response times or by passively observing the victim's login request timing. The attacker then generates candidate values for the OAuth2 state and PKCE parameters using the same PRNG algorithm and seed approximation.

Stage 3 — Payload/Execution.
Using the predicted parameter values, the attacker crafts a malicious OAuth login URL. For login CSRF (state prediction), the attacker sends this URL to a legitimate admin user (simulating an admin inviting a user, or via a phishing email). When the admin clicks and completes SSO login, the authorization code is bound to the attacker's predicted state value. The attacker then exchanges the authorization code using a predicted PKCE code_verifier, completing the login as the victim/admin. Alternatively, if no PKCE is used, the attacker directly injects a valid state to bind the session to their own browser session, resulting in session fixation.

Stage 4 — Post-Exploitation Impact.
Once authenticated with admin privileges, the attacker can view, edit, and deploy applications across all configured Kubernetes clusters, modify application repositories, create or delete projects, access stored secrets/tokens, and further pivot to the Kubernetes cluster itself (e.g., by deploying malicious manifests). Since Argo CD has read/write access to the target clusters, the attacker effectively gains cluster-level privileges.

No public PoC is available for this CVE; the attack chain is inferred from the vulnerability class (insufficient entropy in OAuth2/OIDC parameters) and standard OAuth attack techniques.

Impact Assessment

CVSS Score: 8.3 (High) — The vector is not explicitly provided, but based on the attack characteristics (network-based, requires user interaction/phishing, high confidentiality/integrity/availability impact) the most plausible vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H. The scope is changed (S:C) because the compromise of Argo CD login flow can impact the underlying Kubernetes clusters.

Confidentiality/Integrity/Availability (C/I/A): All rated High, because an admin-level compromise of Argo CD grants read access to sensitive deployment configurations, secrets, and cluster credentials; write access to modify/deploy workloads; and the ability to disrupt services.

Blast Radius: Argo CD is used as the central control plane for GitOps deployments. A compromised instance impacts every application, namespace, and Kubernetes cluster managed by it. In multi-tenant setups, the attacker can move laterally across clusters and potentially to adjacent systems via stored cloud credentials.

Who is affected: Any organization running Argo CD v0.11.0 through v2.1.15, v2.2.0–v2.2.9, v2.3.0–v2.3.4, and v2.4.0–v2.4.0 with SSO/OIDC login configured. Instances using local user authentication only (no SSO) are not exposed to this specific flow flaw, but the SSO-related vulnerability remains if SSO is later enabled.

EPSS score 0.00894 (56.1 percentile) indicates low exploitation probability in the wild, consistent with the difficulty of the attack. CISA KEV does not list this CVE, and no public PoC or exploit code has been found. However, the severity remains High due to the privileged access gain potential.

Detection Guidance

Sigma Rule

title: Argo CD OAuth2/OIDC Login Rate Anomaly or Irregular State/PKCE Parameter
id: 8d6a1d91-4d7e-4b2e-9a3f-1c0e9b6d2f7a
status: experimental
description: Detects abnormal volume of OAuth2/OIDC login attempts to Argo CD or observable repeated patterns in login parameters, indicative of attempted PRNG state prediction.
author: valtersit.com Threat Intel
date: 2025/04/14
logsource:
  category: web
  product: argo-cd
detection:
  selection:
    cs-method: POST
    cs-uri-path:
      - /auth/login
      - /api/v1/session
    cs-uri-query|contains: 
      - 'state='
      - 'code_challenge='
  anomaly:
    cs-uri-query|re: 'state=[a-zA-Z0-9]{1,8}'  # suspiciously short state parameter
  condition: selection and anomaly
falsepositives:
  - Legitimate SSO configuration with short state parameters (rare)
  - Testing environments
level: medium

YARA Rule

rule ArgoCD_OAuth_Predictable_State
{
    meta:
        author = "valtersit.com Threat Intel"
        description = "Detects Argo CD login request bodies with suspiciously short or repeated OAuth state or PKCE parameters"
        date = "2025-04-14"
        reference = "CVE-2022-31034"
    strings:
        $s_short_state = /state=[a-zA-Z0-9\-_]{1,8}/ nocase
        $s_short_verifier = /code_verifier=[a-zA-Z0-9\-_]{1,16}/ nocase
        $s_repeated_state = /state=([a-zA-Z0-9\-_]+).*?state=\1/ nocase
    condition:
        any of them
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2022-31034 Argo CD OAuth Login - Suspiciously Short state/PKCE Parameter"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/auth/login"; http.request_body; pcre:"/state=[a-zA-Z0-9\-_]{1,8}/i"; classtype:attempted-user; sid:5000401; rev:1;)

Elastic Detection

sequence by host.id with maxspan=5m
  [ network where event.action == "connection_established" and destination.port in (8080, 8443) ]
  [ http where http.request.method == "POST" and http.request.uri == "/auth/login" and url.query : "*state=*"
    and (/* detect short state parameter (<=8 chars) */
         regex(url.query, "state=[a-zA-Z0-9\\-_]{1,8}", ".*state=[a-zA-Z0-9\\-_]{1,8}.*")) ]
  [ http where http.request.method == "POST" and http.request.uri == "/auth/login" and url.query : "*code_challenge=*"
    and (regex(url.query, "code_challenge=[a-zA-Z0-9\\-_]{1,16}", ".*code_challenge=[a-zA-Z0-9\\-_]{1,16}.*")) ]

Splunk SPL Query

index=web sourcetype=access_combined uri="/auth/login" method="POST"
| rex field=uri_query "(?<state_param>state=[a-zA-Z0-9\-_]{1,8})"
| rex field=uri_query "(?<code_challenge_param>code_challenge=[a-zA-Z0-9\-_]{1,16})"
| where state_param OR code_challenge_param
| stats count by src_ip uri uri_query state_param code_challenge_param _time
| where count > 5
| table _time src_ip uri state_param code_challenge_param count

Wazuh OSSEC Rule

<group name="argo_cd,">
  <rule id="100501" level="12">
    <decoded_as>json</decoded_as>
    <field name="url">/auth/login</field>
    <field name="method">POST</field>
    <regex>state=[a-zA-Z0-9\-_]{1,8}</regex>
    <description>Argo CD OAuth login attempted with suspiciously short state parameter - possible CVE-2022-31034 exploitation</description>
    <group>authentication_failures,attack</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 — UNPATCHED — no patch evidence from any tracked source.
Despite the NVD description explicitly listing fixed versions (v2.4.1, v2.3.5, v2.2.10, v2.1.16), our patch-tracking sources report no patch evidence. The absence of patch evidence likely indicates a tracking data gap rather than a genuine lack of a fix. Nonetheless, the following guidance is given with the explicit caveat that the patch status must be confirmed directly from the Argo CD release announcements.

1. Immediate Mitigations (until patch is confirmed/verified):

   • Restrict network access to the Argo CD server/API to trusted networks/VPN only.
   • Enforce multi-factor authentication at the SSO identity provider to add an extra layer of verification beyond the OAuth state/PKCE parameters.
   • Disable SSO login and use local Argo CD user accounts with strong passwords as a temporary measure, if operationally feasible.
   • Enable strict session timeout and monitor login events for anomalies (repeated failed logins, unusual timings).

2. Patch/Upgrade Steps:

   • Confirm the vulnerability status from the official Argo CD GitHub advisories (GHSA) and the release notes for the listed versions.
   • Upgrade Argo CD to the latest patched version: v2.4.1 (or later 2.4.x), v2.3.5+, v2.2.10+, or v2.1.16+. For production, upgrade to the most recent stable release available at the time of remediation.
   • Full upgrade procedure: back up the Argo CD configuration (ConfigMap, secrets, applications), then use the official upgrade guides (argocd CLI or Helm chart upgrade), and verify health of the core components after upgrade.

3. Long-Term Hardening:

   • Keep Argo CD up to date with the latest stable release.
   • Restrict access to the Argo CD UI/API with network policies, and consider SSO with strong PKCE enforcement if the identity provider supports it.
   • Audit all OAuth2/OIDC configurations; ensure TLS is enforced end-to-end.
   • Implement additional monitoring on the login flow (rate-based alerts, short-parameter detection).

References

1. NVD — CVE-2022-31034: https://nvd.nist.gov/vuln/detail/CVE-2022-31034
2. GitHub Advisory (Argo CD): https://github.com/argoproj/argo-cd/security/advisories (search for CVE-2022-31034 or the related GHSA)
3. Argo CD Release Notes: https://github.com/argoproj/argo-cd/releases (v2.4.1, v2.3.5, v2.2.10, v2.1.16)
4. CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog (CVE not listed — no known in-the-wild exploitation as of this report)
5. EPSS Model (FIRST.org): https://www.first.org/epss/

No threat-actor campaigns or in-the-wild exploitation have been publicly reported for this CVE as of the writing of this report.