GHSA-cwxv-4866-5gq2: Shamir backup recovery accepts a share at x = 0, so a supplied share can substitute the recovered private key

KeyShares::frombackupformat (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::recoverprivatekey 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.