Zt Zip
Monthly
ZipUtil.unpack in zt-zip 1.18.0 and earlier can rewrite the permissions of the extraction output directory itself when an untrusted ZIP contains a self-referencing entry such as '/' or './' that carries attacker-chosen stored Unix mode bits. Applications that unpack attacker-supplied archives are affected; a restrictive output directory (for example owner-only) can be made readable, writable and executable by every local user, weakening the isolation of everything written under it. A public proof-of-concept snippet is included in the vendor's GitHub security advisory; it is not verified as working exploit code against third-party applications, and there is no CISA KEV confirmation, so active exploitation is not established. The vendor-released patch is zt-zip 1.18.1, and the project's priority label places this in the 'this month' remediation window rather than an emergency tier.
Path traversal in the zt-zip Java library's Zips fluent unpack API lets a malicious archive entry such as '../escape/poc.txt' (or a trailing-slash directory entry like '../escape/') be written outside the configured destination directory, affecting versions 1.17 and earlier and covering both the normal copy branch and the ZipEntryTransformer branch. Only applications that extract untrusted archives through Zips.get(zip).unpack().destination(dir).process() are exposed; code that uses ZipUtil.unpack(...) is unaffected because that path already performs a destination-boundary check. Rated 6.1 Medium (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:L) with integrity impact only and no direct network trigger, it requires the victim application to process an attacker-supplied archive; a public PoC reference exists in the upstream advisory, and no active exploitation has been confirmed.
zt-zip before 1.13 is vulnerable to directory traversal, allowing attackers to write to arbitrary files via a ../ (dot dot slash) in a Zip archive entry that is mishandled during extraction. Rated medium severity (CVSS 5.5), this vulnerability is no authentication required, low attack complexity. Public exploit code available.
ZipUtil.unpack in zt-zip 1.18.0 and earlier can rewrite the permissions of the extraction output directory itself when an untrusted ZIP contains a self-referencing entry such as '/' or './' that carries attacker-chosen stored Unix mode bits. Applications that unpack attacker-supplied archives are affected; a restrictive output directory (for example owner-only) can be made readable, writable and executable by every local user, weakening the isolation of everything written under it. A public proof-of-concept snippet is included in the vendor's GitHub security advisory; it is not verified as working exploit code against third-party applications, and there is no CISA KEV confirmation, so active exploitation is not established. The vendor-released patch is zt-zip 1.18.1, and the project's priority label places this in the 'this month' remediation window rather than an emergency tier.
Path traversal in the zt-zip Java library's Zips fluent unpack API lets a malicious archive entry such as '../escape/poc.txt' (or a trailing-slash directory entry like '../escape/') be written outside the configured destination directory, affecting versions 1.17 and earlier and covering both the normal copy branch and the ZipEntryTransformer branch. Only applications that extract untrusted archives through Zips.get(zip).unpack().destination(dir).process() are exposed; code that uses ZipUtil.unpack(...) is unaffected because that path already performs a destination-boundary check. Rated 6.1 Medium (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:L) with integrity impact only and no direct network trigger, it requires the victim application to process an attacker-supplied archive; a public PoC reference exists in the upstream advisory, and no active exploitation has been confirmed.
zt-zip before 1.13 is vulnerable to directory traversal, allowing attackers to write to arbitrary files via a ../ (dot dot slash) in a Zip archive entry that is mishandled during extraction. Rated medium severity (CVSS 5.5), this vulnerability is no authentication required, low attack complexity. Public exploit code available.