adm-zip EUVD-2026-109389

Exploitation requires the consuming application to use adm-zip's validate-then-extract pattern: it must inspect entry content via getEntry() or readAsText() to approve the archive, then write it out with extractAllTo(). The attacker must craft an archive containing duplicate entries under canonically equivalent names (e.g. './hello.txt' and 'hello.txt') so readEntries() treats them as distinct and the validated entry differs from the extracted one. Limiting factors: only adm-zip through 0.6.1 is affected; the impact is confined to integrity (a wrong file written to an expected path), with no confidentiality or availability effect; and applications that extract without a prior content-validation step gain no security benefit to bypass, so the flaw is inert for them.

This is a medium-severity integrity issue, not a top-tier emergency. The supplied CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N) scores 6.3 and limits impact to the vulnerable system's integrity (VI:L) with no confidentiality (VC:N) or availability (VA:N) effect, matching a validation-bypass rather than code execution. Network reach and no required privileges raise exposure, but the AT:P 'attack requirement' is the key moderator: exploitation only matters when a consuming application uses adm-zip's validate-then-extract pattern. No EPSS score was provided and the CVE is not in CISA KEV, so there is no signal of widespread or active exploitation; the vuln.today decision label is 'this_month', consistent with scheduled remediation rather than act_now/emergency. No explicit 'POC: Publicly available (confirmed)' marker is present in the input, though a VulnCheck advisory and GitHub issue #587 document the mechanism. Overall this is a real but conditional integrity-bypass risk whose impact depends heavily on how downstream applications use the library, not a high-CVSS-but-no-real-risk inflation nor an urgent actively-exploited flaw.

An attacker submits a crafted ZIP archive to an application that first inspects entries with getEntry() or readAsText() to approve their content, then unpacks with extractAllTo(). Because the readEntries() duplicate check is evaded using canonically equivalent names such as './hello.txt' and 'hello.txt', the validator sees benign content while extraction writes the malicious variant to the same path, defeating the integrity check. No confirmed working exploit code is marked in the input; VulnCheck's advisory and GitHub issue #587 describe the technique.