This project might be open to known security vulnerabilities, which can be prevented by tightening the version range of affected dependencies. Find detailed information at the bottom.

Crate zip

Dependencies

(12 total, 4 outdated, 2 possibly insecure)

CrateRequiredLatestStatus
 aes^0.8.20.8.4up to date
 byteorder^1.4.31.5.0up to date
 bzip2 ⚠️^0.4.30.6.1out of date
 constant_time_eq^0.1.50.4.2out of date
 crc32fast^1.3.21.5.0up to date
 crossbeam-utils^0.8.80.8.21up to date
 flate2^1.0.231.1.9up to date
 hmac^0.12.10.12.1up to date
 pbkdf2^0.11.00.12.2out of date
 sha1^0.10.10.10.6up to date
 time ⚠️^0.3.70.3.47maybe insecure
 zstd^0.11.20.13.3out of date

Dev dependencies

(4 total, 1 outdated, 1 possibly insecure)

CrateRequiredLatestStatus
 bencher^0.1.50.1.5up to date
 getrandom^0.2.50.4.2out of date
 time ⚠️^0.3.70.3.47maybe insecure
 walkdir^2.3.22.5.0up to date

Security Vulnerabilities

bzip2: bzip2 Denial of Service (DoS)

RUSTSEC-2023-0004

Working with specific payloads can cause a Denial of Service (DoS) vector.

Both Decompress and Compress implementations can enter into infinite loops given specific payloads entered that trigger it.

The issue is described in great detail in the bzip2 repository issue.

Thanks to bjrjk for finding and providing the patch for the issue and the maintainer responsibly responding to release a fix quickly.

Users who use the crate with untrusted data should update the bzip2 to 0.4.4.

time: Denial of Service via Stack Exhaustion

RUSTSEC-2026-0009

Impact

When user-provided input is provided to any type that parses with the RFC 2822 format, a denial of service attack via stack exhaustion is possible. The attack relies on formally deprecated and rarely-used features that are part of the RFC 2822 format used in a malicious manner. Ordinary, non-malicious input will never encounter this scenario.

Patches

A limit to the depth of recursion was added in v0.3.47. From this version, an error will be returned rather than exhausting the stack.

Workarounds

Limiting the length of user input is the simplest way to avoid stack exhaustion, as the amount of the stack consumed would be at most a factor of the length of the input.