adm-zip EUVD-2026-106907

Exploitation requires the consuming application to follow a validate-then-extract pattern on untrusted input: it must inspect a named entry's content via getEntry(name).getData() and trust that result, then call extractAllTo() (synchronous, default overwrite policy) on the same archive. The attacker must craft a ZIP containing two entries with the identical name so getEntry() resolves the last duplicate (via entryTable) while extractAllTo() writes the first (via entryList). LIMITING FACTORS: this is NOT exploitable against applications that simply extract without a getEntry-based content check, nor against versions 0.6.1 and later; the AC:H and AT:P metrics reflect that the specific duplicate-name ordering and the application's check-then-extract logic must both align for the bypass to succeed.

This is a genuine-but-conditional integrity risk rather than a blanket critical flaw. The CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:N/UI:N) scores 8.2 with impact confined to integrity (VI:H; VC:N, VA:N), which is consistent with a classic TOCTOU-style validate-then-extract bypass (CWE-436, interpretation conflict). The high attack complexity (AC:H) and present attack requirements (AT:P) are the key moderating signals: exploitation does not work against arbitrary deployments but only against applications that follow a specific check-then-use pattern, so the headline score overstates universal risk. A working PoC is published in the GHSA advisory (publicly available exploit code exists), which raises practical concern, but there is NO CISA KEV listing and NO EPSS score was provided in the input, so there is no evidence of active or widespread exploitation - the risk is best read as library-supply-chain/targeted rather than mass-exploited. Note a signal tension: PR:N labels this unauthenticated, yet real-world impact depends entirely on how the downstream application uses adm-zip, so the 'network unauthenticated' framing applies to delivering the malicious archive, not to a direct service compromise.

An application accepts an untrusted ZIP, calls getEntry('b.txt').getData() to validate that entry's contents against a policy, and after the check passes calls extractAllTo() to unpack the archive. An attacker submits a crafted ZIP containing two entries both named 'b.txt' - a benign one that getEntry() returns for validation and a malicious one that extractAllTo() actually writes to disk. A public PoC demonstrating this exact divergence (validated bytes 'SECOND' vs. written bytes 'FIRST') is included in the GHSA advisory.