RUSTSEC-2023-0033: Parsing borsh messages with ZST which are not-copy/clone is unsound

What to do

1. See which version you have: cargo tree -i borsh (it also shows which of your dependencies pulls it in).
2. Update within your version requirement: cargo update -p borsh. If the fix is a newer major or minor than your requirement allows, raise it in Cargo.toml (for example borsh = "1.0.0-alpha.1") or update the dependency that pulls it in.
3. Check again with cargo audit, or paste your Cargo.lock into our Cargo.toml checker.

Details from the advisory

Affected versions of borsh cause undefined behavior when zero-sized-types (ZST) are parsed and the Copy/Clone traits are not implemented/derived. For instance if 1000 instances of a ZST are deserialized, and the ZST is not copy (this can be achieved through a singleton), then accessing/writing to deserialized data will cause a segmentation fault.

There is currently no way for borsh to read data without also providing a Rust type. Therefore, if not ZST are used for serialization, then you are not affected by this issue.

References

• Package: crates.io/crates/borsh
• Advisory: rustsec.org/advisories/RUSTSEC-2023-0033.html
• Report: github.com/near/borsh-rs/issues/19
• Web: github.com/near/borsh-rs/pull/136

From the RustSec Advisory Database (CC0-1.0) via the OSV export, downloaded Oct 24, 2026. Severity score computed from the published CVSS vector.