Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
5 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
`KVStoreInterpreter::verify_signature_legacy(&PushDrop, &PublicKey)`, public and deprecated since 0.2.0 (the crate's first release), read neither argument and answered `true`. A KVStore token signed by nobody, a signed token checked against a key other than its controller's, and a PushDrop with no fields each passed. Its documentation said it delegated to the `KVStoreFields`-based verifier; it did not. An application that checks, with this function, a KVStore token it did not write (an overlay lookup's answer, or a transaction output a peer hands it) and acts on `true` accepts a value no controller signed, attributed to whatever controller the token names. No caller in the crate itself uses the function. This was run on 0.2.0, 0.5.0, 0.8.0, 0.8.7, 0.8.8, 0.9.0-beta.1 and 0.9.0-beta.7 as crates.io serves them, and the source of all 63 published versions carries the same constant body (the yanked 0.3.21 included). 0.8.9 answers `true` only for a token whose controller field is the…
Recommended action: Upgrade to 0.9.0-beta.7.0 (pre-release) or 0.8.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
`KeyShares::from_backup_format` (the Shamir backup share reader, public since 0.2.0, the crate's first release) accepted a share whose x coordinate is 0, and `KeyShares::recover_private_key` interpolates the shares at x = 0 to recover the key. At an x of 0 the interpolation answers that share's y value alone, so an attacker who supplies one share in that form — with the share's integrity tag ground to match the honest set's — chooses the recovered key outright. The non-canonical zero x = p works the same way, and a repeated x past the threshold window also passed. An application that recovers a Shamir backup from shares it did not produce — a custodian's medium, a share pasted by hand, a set restored from another writer — could be handed the attacker's key as the recovered one. A set the crate's own writer produces never carries such a share; the door is the reader. 0.8.7 refuses such a set before interpolating (the 0.9 line's next prerelease carries the same refusal). Where…
Recommended action: Upgrade to 0.9.0-beta.7.0 (pre-release) or 0.8.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
`Transaction::from_json`, 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`: `source_txid` and `to_json` gave the text back, while `to_binary` 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 `from_json` 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 `from_json`.
Recommended action: Upgrade to 0.9.0-beta.7.0 (pre-release) or 0.8.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
`Signature::from_der` 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::verify_message_der`, `auth::Certificate::verify`, `auth::VerifiableCertificate::verify`, `wallet::ProtoWallet::verify_signature` and `kvstore::KVStoreInterpreter::verify_signature` 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…
Recommended action: Upgrade to 0.9.0-beta.7.0 (pre-release) or 0.8.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
`Transaction::from_binary` and `Transaction::from_hex` read one transaction from the front of their input, did not check that the input ended there, and kept the whole input as the transaction's cached serialization: `to_binary`, `to_hex` and `id()` then answered for bytes that are not the transaction's. `Transaction::from_json`, given a `hex` field, reads it through `from_hex` and answers the same. `from_ef`, `from_hex_ef` and `parse_script_offsets` also read a prefix. An application that takes bytes or hex from outside, parses them with these readers and then uses `id()` or the serialization could be given one transaction under another identity: the same parsed fields, a different id. An application that passes them only bytes it produced or has already checked is not affected. 0.8.5 refuses a byte after the transaction; `Transaction::from_reader` reads from the front of a longer buffer. Where upgrading is not possible, parse with `Transaction::from_binary`, call…
Recommended action: Upgrade to 0.9.0-beta.7.0 (pre-release) or 0.8.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.