RUSTSEC-2026-0501 Shamir backup recovery accepts a share at x = 0, so a supplied share can substitute the recovered private key

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 upgrading is not possible, before recovering
split each share on . into four fields, base58-decode the x field, and
refuse the set if it decodes to zero (the one-character field 1, or a value
at or above the field prime) or if two shares carry the same x.