CVE-2026-4258: sjcl Information Disclosure Vulnerability

CVE-2026-4258 Overview

All versions of the package sjcl (Stanford JavaScript Crypto Library) are vulnerable to Improper Verification of Cryptographic Signature due to missing point-on-curve validation in sjcl.ecc.basicKey.publicKey(). An attacker can recover a victim's ECDH private key by sending crafted off-curve public keys and observing ECDH outputs. The dhJavaEc() function directly returns the raw x-coordinate of the scalar multiplication result without hashing, providing a plaintext oracle without requiring any decryption feedback.

Critical Impact

Attackers can recover ECDH private keys by exploiting the missing curve validation, compromising all encrypted communications relying on the affected cryptographic operations.

Affected Products

• sjcl (Stanford JavaScript Crypto Library) - All versions
• Applications using sjcl for ECDH key exchange operations
• Web applications implementing elliptic curve cryptography via sjcl

Discovery Timeline

• 2026-03-17 - CVE CVE-2026-4258 published to NVD
• 2026-03-17 - Last updated in NVD database

Technical Details for CVE-2026-4258

Vulnerability Analysis

This vulnerability falls under the category of Invalid Curve Attack, a well-known cryptographic weakness where elliptic curve implementations fail to validate that public key points lie on the expected curve. The sjcl library's sjcl.ecc.basicKey.publicKey() function accepts public key points without verifying they are valid curve points, enabling an attacker to submit carefully crafted malicious public keys.

When a victim performs ECDH key agreement using an attacker-supplied off-curve point, the scalar multiplication produces results that leak information about the victim's private key. Because the dhJavaEc() function returns the raw x-coordinate without hashing, attackers gain a direct plaintext oracle. By sending multiple crafted points and analyzing the corresponding outputs, an attacker can mathematically recover the victim's private key through a series of observations.

Root Cause

The root cause is the absence of point validation in the public key constructor. The sjcl.ecc.basicKey.publicKey() function stores the provided point without calling isValid() to confirm the point lies on the expected elliptic curve. This architectural oversight allows off-curve points to be processed as legitimate public keys, enabling invalid curve attacks that can fully compromise private key material.

Attack Vector

The attack vector is network-based and requires no authentication. An attacker initiates ECDH key exchanges with a target application, supplying maliciously crafted public keys that intentionally lie off the legitimate curve. Each off-curve point belongs to a curve with a different (smaller) order, allowing the attacker to extract the victim's private key modulo various small primes. After collecting enough partial information, the attacker uses the Chinese Remainder Theorem to reconstruct the full private key.

The following patch demonstrates the security fix implemented in sjcl:

       this._point = point;
     }
 
+    if (!this._point.isValid()) {
+      throw new sjcl.exception.corrupt("not on the curve!");
+    }
+
     this.serialize = function () {
       var curveName = sjcl.ecc.curveName(curve);
       return {

Source: GitHub SJCL Commit

The patch adds a validation check that throws an exception if the provided point does not pass the isValid() curve membership test, preventing off-curve points from being processed.

Detection Methods for CVE-2026-4258

Indicators of Compromise

• Unusual patterns of failed ECDH key exchanges or repeated key agreement attempts from single sources
• Multiple ECDH operations with varying public keys from the same client in rapid succession
• Cryptographic operation errors or exceptions related to invalid point calculations
• Anomalous network traffic patterns suggesting key recovery attack sequences

Detection Strategies

• Implement application-level logging for all ECDH key exchange operations, capturing public key metadata
• Deploy software composition analysis (SCA) tools to identify sjcl dependencies in your codebase
• Monitor for unusual cryptographic operation patterns that may indicate active exploitation attempts
• Review application logs for sjcl-related exceptions or cryptographic errors

Monitoring Recommendations

• Enable verbose logging for cryptographic operations in applications using sjcl
• Set up alerts for multiple failed or suspicious ECDH key agreement attempts
• Conduct regular dependency audits to identify vulnerable sjcl versions
• Monitor security advisories from Snyk and npm for sjcl-related updates

How to Mitigate CVE-2026-4258

Immediate Actions Required

• Audit all projects for sjcl dependencies using npm ls sjcl or equivalent package manager commands
• Update sjcl to a patched version that includes the isValid() check (see commit ee307459)
• Review any custom implementations using sjcl.ecc.basicKey.publicKey() for proper input validation
• Consider migrating to actively maintained cryptographic libraries such as the Web Crypto API

Patch Information

A security patch has been committed to the sjcl repository that adds point-on-curve validation. The fix adds an isValid() check in the public key constructor that throws a sjcl.exception.corrupt exception when an off-curve point is detected. Organizations should update to a version containing this patch or apply the fix manually if using a vendored copy of sjcl. For detailed patch information, refer to the Snyk vulnerability report.

Workarounds

• Implement application-level validation of all incoming public keys before passing to sjcl
• Wrap ECDH operations with custom point validation using the curve equation
• Consider using alternative cryptographic libraries with robust input validation such as the native Web Crypto API
• Restrict ECDH key exchange endpoints to authenticated clients to limit attack surface

# Check for vulnerable sjcl installations
npm ls sjcl

# Update sjcl to latest version
npm update sjcl

# Audit dependencies for known vulnerabilities
npm audit