VYPR
← All advisories
High severityNVD Advisory· Published Jun 4, 2020· Updated Aug 4, 2024

CVE-2020-13822

CVE-2020-13822

Description

The Elliptic package 6.5.2 for Node.js allows ECDSA signature malleability via variations in encoding, leading '\0' bytes, or integer overflows. This could conceivably have a security-relevant impact if an application relied on a single canonical signature.

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

Elliptic 6.5.2 for Node.js has ECDSA signature malleability due to missing encoding checks, allowing multiple valid signatures for a message.

Vulnerability

Overview

The Elliptic package version 6.5.2 for Node.js contains a vulnerability in its ECDSA signature verification that allows signature malleability. The root cause is the lack of proper encoding checks on the DER-encoded signature before verification. According to the issue report [1], the verification function accepts signatures with various non-standard encodings that deviate from the X.690 standard, such as long form encoding of length, leading zero bytes in length fields, integer overflows in length fields, and prepending zeros to integers. These variations produce byte sequences that are not strictly canonical but still mathematically verify as valid ECDSA signatures.

Exploitation and

Attack Surface

An attacker can exploit this by taking a valid ECDSA signature and modifying its DER encoding in one of the accepted malleable ways, resulting in a new byte sequence that still passes verification for the same public key and message hash. The attack requires no additional authentication or network position beyond the ability to present a modified signature to a verifier. The Google Wycheproof test vectors demonstrate that signatures with long form length encoding, leading zeros, or integer overflow are incorrectly accepted [1]. This malleability is inherent to the verification algorithm not rejecting non-canonical encodings.

Impact

If an application relies on the uniqueness or canonical form of a signature for security decisions, this malleability can have serious consequences. For example, in blockchain or cryptocurrency systems, a signature might be used as a transaction identifier; malleable signatures could allow an attacker to create a modified but valid transaction that changes the transaction hash without invalidating the signature. This could lead to double-spending or replay attacks [3]. The impact is context-dependent, but any system that uses the signature bytes as a unique identifier or assumes signature immutability is at risk.

Mitigation

The vulnerability is fixed in Elliptic version 6.5.3. Users should update to the latest version immediately [4]. There is no official workaround in the 6.5.2 release, but developers can implement additional validation of signature encoding to reject non-canonical DER sequences. The CVE notes that this issue could have a security-relevant impact if an application relied on a single canonical signature [2].

References
  1. Lack of encoding checks allows a certain degree of signature malleability in ECDSA signatures
  2. NVD - CVE-2020-13822
  3. How Not to Use ECDSA
  4. GitHub - indutny/elliptic: Fast Elliptic Curve Cryptography in plain javascript

AI Insight generated on May 21, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.

Affected packages

Versions sourced from the GitHub Security Advisory.

PackageAffected versionsPatched versions
ellipticnpm
< 6.5.36.5.3

Affected products

2
  • Node.js/Elliptic package for Node.jsdescription
  • ghsa-coords
    pkg:npm/elliptic
    Range: < 6.5.3

Patches

1
856fe4d99fe7

signature: prevent malleability and overflows

https://github.com/indutny/ellipticFedor IndutnyJun 18, 2020via ghsa
commit
1 file changed · +36 −4
  • lib/elliptic/ec/signature.js+36 −4 modified
    @@ -32,11 +32,24 @@ function getLength(buf, p) {
     return initial;
   }
   var octetLen = initial & 0xf;
+
+  // Indefinite length or overflow
+  if (octetLen === 0 || octetLen > 4) {
+    return false;
+  }
+
   var val = 0;
   for (var i = 0, off = p.place; i < octetLen; i++, off++) {
     val <<= 8;
     val |= buf[off];
+    val >>>= 0;
   }
+
+  // Leading zeroes
+  if (val <= 0x7f) {
+    return false;
+  }
+
   p.place = off;
   return val;
 }
@@ -60,28 +73,47 @@ Signature.prototype._importDER = function _importDER(data, enc) {
     return false;
   }
   var len = getLength(data, p);
+  if (len === false) {
+    return false;
+  }
   if ((len + p.place) !== data.length) {
     return false;
   }
   if (data[p.place++] !== 0x02) {
     return false;
   }
   var rlen = getLength(data, p);
+  if (rlen === false) {
+    return false;
+  }
   var r = data.slice(p.place, rlen + p.place);
   p.place += rlen;
   if (data[p.place++] !== 0x02) {
     return false;
   }
   var slen = getLength(data, p);
+  if (slen === false) {
+    return false;
+  }
   if (data.length !== slen + p.place) {
     return false;
   }
   var s = data.slice(p.place, slen + p.place);
-  if (r[0] === 0 && (r[1] & 0x80)) {
-    r = r.slice(1);
+  if (r[0] === 0) {
+    if (r[1] & 0x80) {
+      r = r.slice(1);
+    } else {
+      // Leading zeroes
+      return false;
+    }
   }
-  if (s[0] === 0 && (s[1] & 0x80)) {
-    s = s.slice(1);
+  if (s[0] === 0) {
+    if (s[1] & 0x80) {
+      s = s.slice(1);
+    } else {
+      // Leading zeroes
+      return false;
+    }
   }
 
   this.r = new BN(r);

Vulnerability mechanics

Generated on May 9, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.

References

9

News mentions

0

No linked articles in our index yet.