CVE-2022-21449: Oracle GraalVM RCE Vulnerability

CVE-2022-21449 Overview

CVE-2022-21449, widely known as "Psychic Signatures," is a critical cryptographic vulnerability affecting Oracle Java SE and Oracle GraalVM Enterprise Edition. The flaw exists in the Libraries component, specifically in the implementation of Elliptic Curve Digital Signature Algorithm (ECDSA) signature validation. This vulnerability allows unauthenticated attackers with network access to bypass signature verification entirely by supplying specially crafted signatures with zero values, effectively undermining the integrity guarantees of ECDSA-signed data.

The vulnerability is particularly dangerous because ECDSA signatures are widely used in TLS certificates, JWT tokens, SAML assertions, and WebAuthn/FIDO authentication. An attacker can forge signatures that the vulnerable Java implementation will accept as valid, enabling unauthorized access to protected resources, man-in-the-middle attacks on TLS connections, and authentication bypass scenarios.

Critical Impact

Attackers can forge ECDSA signatures using zero-value parameters (r=0, s=0), completely bypassing cryptographic signature verification in affected Java versions. This enables TLS certificate forgery, JWT token manipulation, and authentication bypass.

Affected Products

• Oracle Java SE 17.0.2 and 18
• Oracle GraalVM Enterprise Edition 21.3.1 and 22.0.0.2
• Azul Zulu 15.38, 17.32, and 18.28
• Debian Linux 10.0 and 11.0
• NetApp Active IQ Unified Manager (Windows/vSphere)
• NetApp OnCommand Insight
• NetApp Cloud Insights
• NetApp E-Series SANtricity products

Discovery Timeline

• April 19, 2022 - CVE-2022-21449 published to NVD
• April 2022 - Oracle releases security patch in Critical Patch Update
• November 21, 2024 - Last updated in NVD database

Technical Details for CVE-2022-21449

Vulnerability Analysis

The vulnerability stems from a fundamentally flawed implementation of ECDSA signature verification in Java's cryptographic libraries. In ECDSA, a valid signature consists of two integers, r and s, which must satisfy specific mathematical relationships based on the message hash and the signer's public key. A properly implemented verification routine must validate that both r and s are non-zero and within the valid range of the elliptic curve's order.

The vulnerable Java implementation fails to check whether r and s are zero before proceeding with signature verification. When an attacker supplies a signature where both r and s equal zero, the verification mathematics degenerates in a way that causes the implementation to incorrectly accept the signature as valid. This is trivially exploitable—any attacker can forge a valid-appearing signature for any message without possessing the private key.

The impact extends to any Java application relying on ECDSA for security, including TLS client certificate validation, JWT token verification, SAML assertion validation, and WebAuthn/FIDO2 authentication flows. The network-accessible attack vector requires no authentication, making it especially dangerous for internet-facing services.

Root Cause

The root cause is the absence of proper validation checks in the ECDSA signature verification code path. According to the ECDSA standard (SEC 1, Version 2.0, Section 4.1.4), implementations must verify that both signature components r and s are integers in the interval [1, n-1] where n is the order of the elliptic curve group. The vulnerable implementation failed to enforce this constraint, accepting zero values that should have been rejected immediately.

This oversight was introduced during a reimplementation of Java's elliptic curve cryptography in native Java code. The new implementation missed the critical boundary checks that were present in earlier versions using different underlying libraries.

Attack Vector

The attack vector is network-based with low complexity and requires no privileges or user interaction. An attacker can exploit this vulnerability through multiple protocols including:

1. TLS/HTTPS: Forging server or client certificates signed with ECDSA
2. JWT Tokens: Creating forged tokens with ES256, ES384, or ES512 algorithms
3. SAML Assertions: Bypassing identity provider signature validation
4. WebAuthn/FIDO2: Forging authenticator attestation and assertion signatures
5. Code Signing: Bypassing signed JAR verification

func signGeneric(priv *PrivateKey, csprng *cipher.StreamReader, c elliptic.Curve, hash []byte) (r, s *big.Int, err error) {
        // SEC 1, Version 2.0, Section 4.1.3
        // CVE-2022-21449 - Modified and removed all calculations. Return r = s = 0
        r = new(big.Int)
        s = new(big.Int)
        return
}

Source: CVE-2022-21449 TLS PoC Repository

Detection Methods for CVE-2022-21449

Indicators of Compromise

• ECDSA signatures containing zero values for r or s parameters in TLS handshakes, JWTs, or other signed data
• Authentication successes with malformed or unusually short signature values
• Unexpected successful TLS connections with certificates that should fail validation
• JWT tokens with ES256/ES384/ES512 algorithms containing abnormal signature lengths

Detection Strategies

• Monitor Java application logs for cryptographic exceptions or warnings related to signature verification
• Implement network-level inspection for TLS handshakes containing malformed ECDSA signatures
• Deploy endpoint detection rules to identify processes using vulnerable Java versions (17.0.2, 18) performing cryptographic operations
• Create SIEM correlation rules for authentication events involving ECDSA-signed credentials with suspicious timing patterns

Monitoring Recommendations

• Inventory all systems running affected Java versions and prioritize monitoring for those handling authentication or TLS termination
• Enable verbose logging for Java security providers to capture signature verification operations
• Monitor for exploitation attempts using intrusion detection signatures that identify zero-value ECDSA parameters
• Track Java version across the environment and alert on unpatched systems exposed to network traffic

How to Mitigate CVE-2022-21449

Immediate Actions Required

• Upgrade Oracle Java SE to version 17.0.3 or 18.0.1 or later immediately
• Upgrade Oracle GraalVM Enterprise Edition to version 21.3.2 or 22.1.0 or later
• For Azul Zulu users, update to the latest patched versions available from Azul
• Audit applications for ECDSA usage in authentication, TLS, JWT, or code signing workflows
• Consider temporarily switching to RSA-based signatures if immediate patching is not possible

Patch Information

Oracle addressed this vulnerability in the April 2022 Critical Patch Update (CPU). The fix adds proper validation to ensure signature components r and s are non-zero and within the valid range before proceeding with ECDSA verification. Organizations should apply patches from the Oracle Security Alert.

Additional security advisories and patches are available from:

• Debian Security Advisory DSA-5128
• Debian Security Advisory DSA-5131
• NetApp Security Advisory NTAP-20220429-0006

Workarounds

• If patching is delayed, consider using RSA-based algorithms instead of ECDSA for critical signature operations
• Implement additional application-layer signature validation that explicitly checks for zero-value signature components
• Deploy web application firewalls (WAF) or API gateways with rules to detect and block requests containing malformed ECDSA signatures
• Isolate vulnerable Java applications from untrusted network traffic until patches can be applied

# Verify your Java version and check if patching is required
java -version

# Check for vulnerable versions in your environment
find /usr -name "java" -type f -exec {} -version \; 2>&1 | grep -E "17\.0\.[0-2]|18\.0\.0"

# Update Java on Debian/Ubuntu systems
sudo apt update && sudo apt install openjdk-17-jdk

# Verify patch application by checking version is 17.0.3+ or 18.0.1+
java -version 2>&1 | grep -E "17\.0\.[3-9]|17\.0\.[1-9][0-9]|18\.0\.[1-9]|1[9-9]\."