zip vulnerabilities

From 1.3.0 until 9.0.0, the Rust zip library's ZipArchive::extract calls Vec::with_capacity for a symbolic link target using the attacker-controlled ZIP64 uncompressed_size before reading entry data. A small archive can request an impossible capacity, aborting the process in a way that cannot be contained with catch_unwind or a worker thread.

From 7.2.0 until 9.0.0, the Rust zip library's ZipArchive::extract and ZipArchive::extract_unwrapped_root_dir validate symbolic link targets with a lexical prefix comparison rather than resolving each intermediate link. An attacker who knows the extraction destination can create a chain whose apparent target stays under the destination while an intermediate symlink resolves outside it, allowing files to be created or overwritten with the extracting process's privileges.

The zip library for Rust in versions 0.6.0 through 8.x verifies the HMAC of an AES entry only when the data counter reaches zero. If the reader hits the real end of the archive while data_remaining is still positive, or an encrypted entry has no payload, a clean end of stream is returned without comparing the authentication tag. Applications using by_index_decrypt, by_name_decrypt, by_path_decrypt, or password-enabled by_index_with_options can accept modified plaintext without an authentication error.

Through 9.0.4, the Rust zip library's ZipArchive treats Central Directory File Header filenames as authoritative while ZipStreamReader extracts using Local File Header filenames without reconciling the duplicate metadata. A crafted archive can appear benign to a component inspecting the central directory but cause a streaming extractor to write a different attacker-selected path and content.