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:

javascript

       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

bash

# Check for vulnerable sjcl installations
npm ls sjcl

# Update sjcl to latest version
npm update sjcl

# Audit dependencies for known vulnerabilities
npm audit