NanaZip EUVD-2026-42954

Exploitation requires that the target is running NanaZip prior to version 6.5.1749.0 on Windows with the WebAssembly handler included (the default build). The user must actively open or list the contents of a crafted .wasm archive file - passive filesystem presence of the file is insufficient. The attacker requires no privileges on the target system beyond being able to deliver the crafted file. Exploitation is bounded by the requirement for explicit user interaction (UI:P in CVSS 4.0) and by the local attack vector (the handler is not exposed as a network service). The impact is strictly limited to availability of the NanaZip process itself; the operating system and other processes are unaffected.

The CVSS 4.0 base score of 2.4 is an accurate reflection of genuine low severity. AV:L and UI:P together confirm that exploitation requires local file-system access and deliberate user interaction (opening the archive), ruling out remote or opportunistic mass exploitation. PR:L in the provided vector reflects that the triggering user holds at minimum low-level system access. Impact metrics (VA:L only, VC/VI/SC/SI/SA all N) confirm that the worst outcome is a NanaZip process crash - not code execution, not privilege escalation, not data exfiltration. No EPSS score was provided in the source data, and the vulnerability is absent from CISA KEV, consistent with no confirmed active exploitation. The three fix commits indicate the flaw spans multiple code paths, but the consistent impact class (DoS only) keeps overall risk low. This is a quality-and-reliability issue more than a security priority: organizations should patch on their normal update cadence rather than treating it as an emergency.

An attacker crafts a minimal WebAssembly file with NameSize or Information.Size fields set to values near 2^32, resulting in a file of a few kilobytes on disk. The file is delivered to a target user via email attachment or shared drive. When the user opens or browses the archive in NanaZip prior to 6.5.1749.0, the WebAssembly handler attempts multi-gigabyte allocations, exhausting available memory and crashing the NanaZip process - no public exploit code exists to automate this, but the technique follows directly from the described root cause.