zt-zip CVE-2026-63499

The application must call one of the ZipUtil.unpack overloads on an attacker-controlled (untrusted) ZIP file, and that ZIP must contain an entry whose name resolves to the output directory itself (for example an entry named '/' or './') carrying attacker-chosen stored file permissions (Unix mode / AsiExtraField). The advisory demonstrates the issue directly on POSIX systems; on non-POSIX systems ZTFilePermissionsUtil.fetchDefaultStrategy provides fallback permission handling, so the issue is not strictly limited to POSIX. Limiting factors: affected versions are zt-zip <= 1.18.0 only; the vector is local with required user/application interaction (the target must choose to unpack the untrusted archive, UI:P); the impact is confined to changing the output directory's own permissions rather than arbitrary file write or code execution.

This is a genuine but moderate-priority issue, not a top-tier emergency. The vendor CVSS 4.0 score is 6.9 (Medium) with vector AV:L/AC:L/AT:N/PR:N/UI:P, meaning exploitation is local and depends on the victim application actively unpacking an attacker-supplied ZIP (passive user interaction), which substantially limits mass, remote, unauthenticated exploitation despite PR:N. The vuln.today Decision label is 'this_month' - a scheduled-remediation signal, not 'act_now' or 'emergency' - which aligns with the Medium severity. It is NOT in CISA KEV (no confirmed active exploitation) and no EPSS score was provided in the input, so exploitation-probability cannot be quantified here. A full working proof-of-concept is published inside the GHSA-v2g6-7r9j-v6px advisory, so weaponization effort is low, but PoC availability is a distinct signal from active exploitation and must not be conflated with it. The impact is also narrow: the flaw rewrites the permissions of the extraction output directory itself (VI:H, VA:L, VC:N) rather than achieving code execution or data theft directly. Net: real and worth patching on a normal cycle, driven more by ease of PoC and the clear fix than by any evidence of widespread attack.

An attacker crafts a malicious ZIP whose entry name is '/' (or './') carrying a permissive stored Unix mode, and delivers it to an application that calls ZipUtil.unpack on untrusted archives. Because the path-traversal check allows the self-referencing entry, the unpacker applies those attacker-supplied permissions to the output directory itself - for example turning a previously owner-only directory into one readable/writable/executable by all OS users. A complete Java proof-of-concept demonstrating this on POSIX systems is published in the GHSA advisory.