RUSTSEC-2026-0497: Transaction::from_json holds an input txid that is not 64 hex digits and writes the input as spending the zero txid
Transaction::fromjson, for a document with no hex member, held each input's txid member as given. An input txid that is not 64 hex digits ("zz", "", 63 or 65 digits, characters that are not hex digits) answered Ok: sourcetxid and tojson gave the text back, while tobinary wrote the input as spending the txid of 32 zero bytes and id() hashed those bytes. Documents naming different texts were one transaction, spending an outpoint none of them named.
An application that reads a peer's transaction document with fromjson and relies both on the text of its inputs and on its bytes or id() is affected; one that reads only documents it produced is not.
0.8.6 refuses such a txid (Invalid txid of input N: expected 64 hex digits). Where upgrading is not possible, require each input's txid to be 64 ASCII hex digits before calling fromjson.
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
Where upgrading is not possible, require each input's txid to be exactly 64 ASCII hexadecimal digits before calling from_json.
Event History
Frequently Asked Questions
Which applications are exposed to this issue?
Applications that parse transaction documents received from peers with Transaction::from_json and rely on both the textual input txid values and the resulting binary serialization or id() are affected. Applications that parse only transaction documents they generated are not affected.
What does an attacker need to provide to trigger the inconsistency?
The attacker needs to supply a transaction document without a hex member containing an input txid that is not exactly 64 ASCII hexadecimal digits. Examples include an empty value, non-hex characters such as "zz", or values with 63 or 65 digits.
What happens when an invalid input txid is processed?
The parser can return Ok and preserve the supplied text in source_txid and to_json, but to_binary serializes that input as spending the all-zero 32-byte txid. The id() value is also calculated using the zero txid bytes, so differently named inputs can produce the same transaction.
How can this be mitigated if upgrading is not immediately possible?
Validate every input txid before calling Transaction::from_json. Require it to contain exactly 64 ASCII hexadecimal digits.
What version changes the behavior?
Version 0.8.6 rejects invalid input txids with an error stating that the input txid must contain 64 hex digits.