The bsv-rs crate's Shamir backup recovery mechanism accepted shares with an x coordinate of 0, allowing an attacker to supply a crafted share that directly determines the recovered private key. This flaw existed since the crate's first release (0.2.0) and was fixed in versions 0.8.7 and 0.9.0-beta.7.0. The vulnerability allows an attacker to substitute the recovered private key if the application recovers a Shamir backup from shares it did not originally produce.
The bsv-rs library's Signature::from_der function leniently parses DER-encoded ECDSA signatures, allowing signatures with extra trailing bytes, incorrect sequence lengths, or unnecessary leading zeros in R or S values. This leniency causes multiple distinct byte strings to verify as the same signature over the same data, potentially impacting applications that compare, hash, or store signature bytes. The issue is fixed in versions 0.8.6 and 0.9.0-beta.7.0, which reject these malformed signatures. However, signature byte uniqueness is not fully guaranteed due to the nature of ECDSA's low-S normalization.
The bsv-rs library's Transaction::from_json method improperly handles input transaction IDs (txid) that are not exactly 64 hexadecimal digits. When such invalid txids are parsed, the method returns Ok but internally treats the input as spending a zeroed-out txid, causing inconsistent transaction identification. This affects applications that parse peer transaction documents and rely on both textual and binary representations of inputs. Versions prior to 0.8.6 and certain beta versions before 0.9.0-beta.7.0 are affected. The issue is fixed in versions 0.8.6 and 0.9.0-beta.7.0.
The bsv-rs library versions before 0.8.5 and certain beta versions allow validation functions to incorrectly accept raw byte entries that are not valid transactions. This can lead to treating invalid data as valid transaction IDs and accepting entries that name these invalid entries as parents. The issue is fixed in versions 0.8.5 and 0.9.0-beta.7.0.
The bsv-rs library versions before 0.8.5 and certain beta versions allow transaction readers to accept trailing bytes after a parsed transaction. This causes the transaction's cached serialization and ID to include extra bytes, potentially resulting in a transaction being identified by a different ID than expected. The issue is fixed in versions 0.8.5 and 0.9.0-beta.7.0.