CVE-2023-22899: Zip4j Information Disclosure Vulnerability

CVE-2023-22899 Overview

CVE-2023-22899 is a cryptographic vulnerability in Zip4j through version 2.11.2, a popular Java library for handling ZIP archives. The library, which is used in products such as Threema, does not always verify the Message Authentication Code (MAC) when decrypting a ZIP archive. This missing integrity check allows attackers to potentially tamper with encrypted ZIP archive contents without detection, undermining the confidentiality guarantees expected from encrypted archives.

Critical Impact

Attackers can modify encrypted ZIP archive contents without the application detecting the tampering, enabling potential data integrity attacks on applications relying on Zip4j for secure archive handling.

Affected Products

• Zip4j versions through 2.11.2
• Threema and other products utilizing vulnerable Zip4j versions
• Applications using zip4j_project zip4j library

Discovery Timeline

• 2023-01-10 - CVE-2023-22899 published to NVD
• 2025-04-09 - Last updated in NVD database

Technical Details for CVE-2023-22899

Vulnerability Analysis

This vulnerability is classified under CWE-346 (Origin Validation Error), which relates to the failure to properly validate the origin or authenticity of data. In the context of Zip4j, the library implements AES encryption for ZIP archives but fails to consistently verify the MAC during the decryption process. The MAC serves as a cryptographic checksum that ensures the encrypted data has not been modified since encryption.

When Zip4j decrypts an AES-encrypted ZIP archive, it should verify the MAC to confirm data integrity before presenting the decrypted contents to the application. The vulnerability arises because this verification step is not always performed, creating a window where an attacker could modify the ciphertext in the archive. Without MAC verification, the library cannot detect such modifications, and the application receives potentially tampered data without any warning.

The attack requires network access and involves high complexity, as the attacker must intercept or modify ZIP archives in transit or at rest. While no privileges are required and no user interaction is needed, successful exploitation directly impacts data integrity.

Root Cause

The root cause of CVE-2023-22899 lies in the inconsistent implementation of MAC verification within Zip4j's decryption routines. During the decryption of AES-encrypted ZIP entries, the library should always compute and compare the MAC of the decrypted data against the stored authentication tag. However, certain code paths in versions through 2.11.2 bypass or omit this critical verification step, allowing modified ciphertext to pass through without raising an integrity error.

Attack Vector

The attack vector is network-based, meaning an attacker positioned to intercept or modify ZIP archives during transmission could exploit this vulnerability. The attack scenario involves:

1. An attacker intercepts an AES-encrypted ZIP archive being transmitted to a target application
2. The attacker modifies the encrypted contents of the archive, manipulating specific bytes of ciphertext
3. The modified archive is delivered to the application using the vulnerable Zip4j library
4. When the application decrypts the archive, Zip4j fails to verify the MAC
5. The tampered data is extracted and processed by the application without any integrity warning

This vulnerability is particularly concerning for applications that rely on encrypted ZIP archives for secure data exchange, backup verification, or secure messaging functionality.

Detection Methods for CVE-2023-22899

Indicators of Compromise

• Unexpected or corrupted data extracted from ZIP archives that were expected to be integrity-protected
• Application errors or anomalies when processing encrypted ZIP files
• Log entries indicating decryption operations completed without MAC verification warnings
• Data inconsistencies in systems that receive ZIP archives from external sources

Detection Strategies

• Audit application dependencies to identify usage of Zip4j versions 2.11.2 or earlier
• Implement network monitoring to detect potentially modified ZIP archives in transit
• Review application logs for decryption operations and verify MAC validation is occurring
• Use software composition analysis (SCA) tools to identify vulnerable Zip4j dependencies

Monitoring Recommendations

• Monitor for unexpected changes in data extracted from encrypted ZIP archives
• Implement integrity checks at the application layer as an additional defense
• Track Zip4j library versions across all applications and services in the environment
• Set up alerts for dependency scanners that flag vulnerable Zip4j versions

How to Mitigate CVE-2023-22899

Immediate Actions Required

• Update Zip4j to the latest version available from the official releases page
• Review all applications using Zip4j and prioritize updates for those handling sensitive data
• Implement application-level integrity verification as a defense-in-depth measure
• Audit recent ZIP archive processing for potential data integrity issues

Patch Information

The vulnerability affects Zip4j through version 2.11.2. Users should upgrade to a patched version by consulting the Zip4j releases page for the latest secure release. The fix ensures that MAC verification is consistently performed during decryption of AES-encrypted ZIP entries.

For detailed technical discussion of this issue, refer to GitHub Issue #485 on the Zip4j repository. Threema users can review the vendor statement for product-specific guidance.

Workarounds

• Implement additional integrity verification at the application layer before trusting extracted data
• Use alternative ZIP libraries with verified MAC checking until Zip4j can be updated
• Restrict processing of ZIP archives to trusted sources only
• Consider wrapping ZIP archives in an additional authenticated encryption layer for high-security scenarios

# Example: Check current Zip4j version in Maven projects
grep -r "zip4j" pom.xml
# Update to latest version in pom.xml:
# <dependency>
#   <groupId>net.lingala.zip4j</groupId>
#   <artifactId>zip4j</artifactId>
#   <version>2.11.5</version> <!-- or latest available -->
# </dependency>