EUVD-2026-42957Severity by source
CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:P/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Attacker must deliver file locally (AV:L, PR:L); victim must open it (UI:R); only NanaZip process crashes with no scope change or C/I impact (S:U, C:N, I:N, A:L).
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
2DescriptionCVE.org
NanaZip is the 7-Zip derivative intended for the modern Windows experience. Prior to 6.5.1749.0, NanaZip's UFS and FFS image handler in NanaZip.Codecs.Archive.Ufs.cpp validates the superblock block size only against the MINBSIZE lower bound and does not validate the fs_fsize fragment size, allowing attacker-controlled 32-bit fields to flow into indirect-block, directory, and extraction buffer allocations. A tiny crafted UFS image can force multi-gigabyte allocations during open or extraction, causing memory exhaustion or process termination. This issue is fixed in version 6.5.1749.0.
AnalysisAI
Memory exhaustion in NanaZip's UFS/FFS archive handler (all versions prior to 6.5.1749.0) allows a local low-privilege attacker to terminate the NanaZip process by delivering a crafted disk image that a user opens. The root cause is missing upper-bound validation of the fs_fsize fragment size field in the UFS superblock - unlike fs_bsize, which is checked against MINBSIZE, fs_fsize flows unchecked into indirect-block, directory, and extraction buffer allocation calculations, enabling a tiny image file to trigger multi-gigabyte heap allocation requests. No public exploit has been identified and this vulnerability is not listed in CISA KEV; the CVSS 4.0 score of 2.4 (Low) reflects the constrained local, user-interaction-required attack path with availability-only impact.
Technical ContextAI
The vulnerable code resides in NanaZip.Codecs.Archive.Ufs.cpp, the handler for UFS (Unix File System) and FFS (Fast File System) disk image formats in NanaZip (CPE: cpe:2.3:a:m2team:nanazip:*:*:*:*:*:*:*:*), a modern Windows-exclusive fork of 7-Zip developed by M2Team. UFS/FFS superblocks contain geometry fields including fs_bsize (block size) and fs_fsize (fragment size) that govern how block addresses, directory sizes, and buffer extents are calculated. NanaZip validates fs_bsize against the MINBSIZE lower bound but omits analogous bounds capping on fs_fsize and related 32-bit geometry fields; these unchecked attacker-controlled values propagate directly into multiplication-based allocation sizing for indirect-block tables, directory entry buffers, and extraction staging areas. CWE-400 (Uncontrolled Resource Consumption) is the root cause class: attacker-supplied numeric input sizes heap allocations without an upper-bound guard, so a well-crafted near-maximum 32-bit value can force the allocator to request gigabytes of memory from a file that may itself be only a few hundred bytes.
RemediationAI
Upgrade NanaZip to version 6.5.1749.0 or later, which introduces proper validation of the fs_fsize fragment size field alongside the existing fs_bsize check; the patched release is available at https://github.com/M2Team/NanaZip/releases/tag/6.5.1749.0 and the specific fix can be reviewed at commit 6415b6bff70bc9c486b49cbbc1982724c67f8338. If immediate upgrade is not feasible, the most actionable compensating control is to instruct users not to open UFS or FFS disk images from untrusted sources in NanaZip; this has no impact on common use cases since these Unix filesystem formats are rarely handled on Windows. Blocking file-type delivery at the email gateway or web proxy for raw disk image extensions (.img, .ufs, .ffs) reduces phishing exposure with minimal operational friction. No other workaround addresses the root cause; the vulnerable allocation path is exercised at archive-open time, so even preview-only access triggers it.
Nanazip versions up to 6.0.1630.0 is affected by loop with unreachable exit condition (infinite loop) (CVSS 7.5).
NanaZip versions 5.0.1252.0 through 6.0.1629.0 contain an out-of-bounds heap read in the .NET Single File bundle parser
NanaZip versions 5.0.1252.0 through 6.5.1637.0 contain an out-of-bounds memory access flaw in the UFS file parser that c
Out-of-bounds memory read in NanaZip versions 5.0.1252.0 through 6.0.1637.x allows local authenticated attackers to disc
NanaZip versions 5.0.1252.0 through 6.0.1629.0 are vulnerable to denial of service through malformed ROMFS archives that
NanaZip versions 5.0.1252.0 through 6.5.1637.x contain an integer underflow in the .NET Single File Application parser t
Heap out-of-bounds read in NanaZip's SquashFS LZ4 decompression handler exposes adjacent heap memory contents when a use
Heap out-of-bounds read in NanaZip's Android Verified Boot (AVB) vbmeta image parser allows unauthenticated remote attac
Heap out-of-bounds read in NanaZip's Android Verified Boot (AVB) vbmeta image parser crashes the application and may lea
Heap out-of-bounds null write in NanaZip's UFS/UFS2 filesystem image parser (versions 5.0.1252.0 through 6.0.1698.0) ena
Stack-based out-of-bounds read in NanaZip's ZealFS v1 filesystem image parser affects versions 5.0.1252.0 through before
Heap out-of-bounds read in NanaZip's inherited 7-Zip LvmHandler component allows an unauthenticated remote attacker to c
Same weakness CWE-400 – Uncontrolled Resource Consumption
View allSame technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today