An issue was discovered in the jsrsasign package through 8.0.18 for Node.js. It allows a malleability in ECDSA signatures by not checking overflows in the length of a sequence and '0' characters appended or prepended to an integer. The modified signatures are verified as valid. This could have a security-relevant impact if an application relied on a single canonical signature.

Affected: npm: jsrsasign

### Impact Jsrsasign supports ECDSA signature validation which signature value is represented by ASN.1 DER encoding. This vulnerablity may accept a wrong ASN.1 DER encoded ECDSA signature such as:

- wrong multi-byte ASN.1 length of TLV (ex. 0x820045 even though 0x45 is correct) - prepending zeros with ASN.1 INTEGER value (ex. 0x00000123 even though 0x0123 is correct) - appending zeros to signature of ASN.1 TLV (ex. 0x3082....1fbc000000 even though 0x3082....1fbc, appending zeros are ignored.)

This vulnerability was fixed by strict ASN.1 DER checking.

Here is an assessment of this vulnerability:

- If you are not use ECDSA signature validation, this vulnerability is not affected. - Not ASN.1 format signature like just concatenation of R and S value is not affected such as Bitcoin. - This vulnerability is affected to all ECC curve parameters. - Risk to accept a forged or crafted message to be signed is low. - Risk to raise memory corruption is low since jsrsasign uses BigInteger class. - ECDSA signatures semantically the same to valid one may be accepted as valid. There are many malleable variants.

As discussed [here](https://crypto.stackexchange.com/questions/24862/ber-or-der-x9-62-for-ecdsa-signature), there is no standards like X9.62 which requires ASN.1 DER. So ASN.1 BER can be applied to ECDSA however most of implementations like OpenSSL do strict ASN.1 DER checking.

### Patches Users using ECDSA signature validation should upgrade to 8.0.19.

### Workarounds Do str…