CVE-2026-4258
Improper Signature Verification in sjcl Enables ECDH Key Recovery
Publication date: 2026-03-17
Last updated on: 2026-03-17
Assigner: Snyk
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| stanford | javascript_crypto_library | From 1.0.0 (inc) to 1.0.8 (inc) |
| stanford | javascript_crypto_library | 1.0.9 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-347 | The product does not verify, or incorrectly verifies, the cryptographic signature for data. |
| CWE-325 | The product does not implement a required step in a cryptographic algorithm, resulting in weaker encryption than advertised by the algorithm. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
[{'type': 'paragraph', 'content': 'CVE-2026-4258 is a vulnerability in the Stanford JavaScript Crypto Library (SJCL) affecting all versions of the sjcl package. It arises because the function sjcl.ecc.basicKey.publicKey() does not properly validate whether an elliptic curve point is on the expected curve before accepting it as a public key.'}, {'type': 'paragraph', 'content': "This missing point-on-curve validation allows an attacker to send specially crafted off-curve public keys to a victim. By analyzing the victim's Elliptic Curve Diffie-Hellman (ECDH) outputs, the attacker can recover the victim's private key."}, {'type': 'paragraph', 'content': 'The vulnerability is worsened by the dhJavaEc() function, which returns the raw x-coordinate of the scalar multiplication result without hashing or additional processing. This behavior acts as a plaintext oracle, leaking information about the private key without requiring any decryption feedback.'}, {'type': 'paragraph', 'content': 'The root cause is that when a point object is passed to the publicKey constructor, it is accepted without calling the isValid() check that would confirm the point lies on the curve. This allows off-curve points to be used in cryptographic operations, enabling an invalid curve attack.'}, {'type': 'paragraph', 'content': "An attacker can exploit this by crafting points on 'virtual' curves with small prime order subgroups, then using the Pohlig-Hellman algorithm and the Chinese Remainder Theorem to reconstruct the victim's full private key."}] [1, 2, 3]
How can this vulnerability impact me? :
This vulnerability can have a severe impact on confidentiality by allowing an attacker to recover your private ECDH key remotely without any special privileges or user interaction.
Once the attacker recovers your private key, they can decrypt communications, impersonate you in cryptographic protocols, or otherwise compromise the security guarantees provided by elliptic curve cryptography.
The vulnerability does not affect integrity or availability, but the loss of confidentiality of private keys is critical in cryptographic systems.
Because the dhJavaEc() function returns raw scalar multiplication results without hashing, the attack can be performed efficiently with a relatively small number of queries.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by testing whether the sjcl.ecc.basicKey.publicKey() function accepts off-curve points without validation. Specifically, crafted off-curve public keys can be sent to the vulnerable system to observe if the dhJavaEc() function returns raw x-coordinates without hashing, which acts as a plaintext oracle leaking private key information.
A proof-of-concept involves sending specially crafted elliptic curve points that do not lie on the expected curve and checking if they are accepted by the publicKey constructor without throwing an error.
While no explicit commands are provided in the resources, detection involves attempting to invoke the vulnerable functions with off-curve points and observing if the system returns raw scalar multiplication results without validation errors.
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to apply the patch introduced in SJCL version 1.0.9, which adds explicit validation to ensure that any elliptic curve point used as a public key is on the expected curve by calling the isValid() method.
If upgrading is not immediately possible, ensure that any input points to the publicKey constructor or to the dh() and dhJavaEc() functions are validated manually to reject off-curve points before processing.
Since SJCL is deprecated and not recommended for new projects, consider migrating to a more secure and actively maintained cryptographic library.