GHSA-fjx5-qpf4-xjf2
Parsing borsh messages with ZST which are not-copy/clone is unsound
GHSA-fjx5-qpf4-xjf2 is a vulnerability with no CVSS score yet in borsh, published April 12, 2023. No source lists public exploit code. Fixed in borsh 1.0.0-alpha.1.
- Severity
- UnratedNo CVSS score yet
- Exploit chance
- UnscoredNo EPSS score yet
- Exploitation
- None knownNot on CISA’s or ENISA’s lists
- Fixed in
1.0.0-alpha.1borsh +2 more
Description
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 you are not using ZST for serialization, then you are not affected by this issue.
Affected packages
What each source reports
GitHub AdvisoriesNo score
Parsing borsh messages with ZST which are not-copy/clone is unsound
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 you are not using ZST for serialization, then you are not affected by this issue.
- Record
GHSA-fjx5-qpf4-xjf2- Updated
- 2026-11-02
OSVNo score
Parsing borsh messages with ZST which are not-copy/clone is unsound
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 you are not using ZST for serialization, then you are not affected by this issue.
- Record
GHSA-fjx5-qpf4-xjf2- Updated
- 2026-11-02
OSVRUSTSEC-2023-0033No score
Parsing borsh messages with ZST which are not-copy/clone is unsound
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.
- Record
RUSTSEC-2023-0033- Updated
- 2026-11-02
History
| Recorded | Changed | Sources |
|---|---|---|
| first indexed | GitHub Advisories, OSV |
Dates are when Every CVE recorded each change. Upstream dates may differ.