RUSTSEC-2026-0499: Signature::from_der reads a signature with bytes after it, a wrong sequence length or an unneeded zero as the signature
Signature::fromder read a DER-encoded ECDSA signature leniently. It read as the signature: the signature followed by other bytes; a sequence length shorter than its contents, or longer with bytes after them (a length byte with its high bit set among them); and an R or S preceded by a zero byte it did not need. It read a lone-zero R or S as zero.
messages::verify, compat::bsm::verifymessageder, auth::Certificate::verify, auth::VerifiableCertificate::verify, wallet::ProtoWallet::verifysignature and kvstore::KVStoreInterpreter::verifysignature read through it, and each verified such a form of a valid signature. Given one signature a key holder made, anyone could produce other byte strings that verify as that signature over the same data. No form verifies over other data: an application that acts on the verdict alone is not affected; one that compares, hashes or stores a signature's bytes is.
0.8.6 refuses each form as Error::InvalidSignature. A signature's bytes are still not unique after the patch: the same signature with S replaced by n - S verifies, so an application that keys on the bytes also requires Signature::islows().
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
rust/bsv-rsto a version that resolves this vulnerability.Fixed in 0.8.6 - Upgrade
Upgrade
rust/bsv-rsto a version that resolves this vulnerability.Fixed in 0.9.0-beta.7.0 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 0.8.6 - Compensating control
For applications that compare, hash, or store signature bytes, require low-S signatures by checking Signature::is_low_s(), because replacing S with n − S still verifies after the patch.
Event History
Frequently Asked Questions
Which applications are materially affected by this issue?
Applications that use the signature bytes as an identifier, compare them, hash them, or store them in a way that assumes a unique encoding are affected. Applications that only act on the signature-verification verdict are not affected.
What does an attacker need to exploit this behavior?
They need one valid signature made by the key holder for the same data. They can then construct different byte strings that verify as that signature, but cannot make those forms verify for other data.
How can I remediate the issue?
Use bsv-rs 0.8.6, which rejects the described malformed encodings with Error::InvalidSignature. If signature bytes are used as keys or identifiers, also require Signature::is_low_s(), because replacing S with n - S still produces a valid signature encoding after the patch.
How can I determine whether my deployment is exposed?
Review whether your code calls the affected verification paths and subsequently compares, hashes, or persists the supplied signature bytes. The affected paths include messages::verify, compat::bsm::verify_message_der, certificate verification, wallet signature verification, and KVStoreInterpreter::verify_signature.