{"aliases":["GHSA-xcc6-f2jq-43x6"],"categories":["crypto-failure"],"crate":"orion","cves":[],"cvss":0.0,"database_specific":{"severity":""},"date":"2026-10-30","deb_packages":[{"crate_name":"cargo-c","deb_name":"cargo-c","version":"0.10.25-1"},{"crate_name":"cargo-outdated","deb_name":"cargo-outdated","version":"0.19.0-4"},{"crate_name":"debcargo","deb_name":"debcargo","version":"2.8.4-5"}],"description":"## Summary\n\n`hazardous::mac::blake2b::Blake2b::reset()` does not correctly reset the state when a key is supplied that has a different length than the one used upon initialization with `hazardous::mac::blake2b::Blake2b::new()`, because it errorneously uses a cached length. \n\n## Impact\n\nInitialization `hazardous::mac::blake2b::Blake2b` with a key of some length `N`, followed by a reset with a key of length `!= N` will produce an incorrect BLAKE2b tag, causing `hazardous::mac::blake2b::Blake2b::verify()` to fail. This means under honest protocol conditions, parties could experience failing tag verifications.\n\n## Resolution\n\nUpgrade to `v0.17.16` or `v0.18.1`.","id":"RUSTSEC-2026-0428","keywords":[],"patched_versions":["^0.17.16",">=0.18.1"],"source":"debian_rustsec","title":"BLAKE2b produces wrong tag when using `reset()` with a different-length key","url":"https://github.com/orion-rs/orion/pull/690"}