RUSTSEC-2026-0529: KVStoreInterpreter::verify_signature_legacy answers true for every token and every key
KVStoreInterpreter::verifysignaturelegacy(&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 given key and whose last field is that key's signature over the others (the 0.9 line's next prerelease carries the same fix). There is no workaround: upgrade to 0.8.9, or, on the 0.9 line, to its next prerelease.
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.9 - 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.9
Event History
Frequently Asked Questions
Which applications are exposed to this issue?
Applications are exposed if they use verify_signature_legacy to validate KVStore tokens received from outside their own trusted writes, such as overlay lookup responses or transaction outputs supplied by peers, and then act on a true result. The crate itself has no callers of this function.
What does an attacker need to exploit it?
An attacker only needs to provide a KVStore token to an application that relies on this function for validation. The token need not be signed, may be checked against a key other than its claimed controller's, and can even be a PushDrop with no fields.
Are default or older versions affected?
The vulnerable function was public and deprecated from version 0.2.0, the first release, and the same constant-true implementation appears in all 63 published versions, including the yanked 0.3.21. Testing confirmed the behavior through 0.9.0-beta.7; version 0.8.9 contains the fix, as does the next 0.9 prerelease.
What should teams do if they use this function?
There is no workaround. Upgrade to 0.8.9, or on the 0.9 line upgrade to its next prerelease carrying the fix.