EUVD-2026-29789Severity by source
AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L
Local file-open attack vector (AV:L, UI:R) with no attacker privileges needed; availability-only impact scoped to the application (A:L, C:N, I:N, S:U).
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
Lifecycle Timeline
3DescriptionGitHub Advisory
NanaZip is an open source file archive. From 5.0.1252.0 to before 6.0.1698.0, a denial-of-service vulnerability exists in the littlefs filesystem image parser in NanaZip. The handler's Open method reads BlockCount directly from the attacker-controlled superblock without any validation against the actual file size or any upper-bound ceiling, then iterates BlockCount times, allocating a file-path entry per iteration. A crafted 44-byte littlefs image with BlockCount = 0xFFFFFFFF causes ~4 billion heap allocations, exhausting available memory. This vulnerability is fixed in 6.0.1698.0.
AnalysisAI
Memory exhaustion in NanaZip's littlefs filesystem image parser (versions 5.0.1252.0 through before 6.0.1698.0) allows a local denial-of-service condition when a victim opens a specially crafted archive. The parser's Open method blindly trusts the attacker-controlled BlockCount superblock field, and a 44-byte littlefs image with BlockCount set to 0xFFFFFFFF triggers approximately 4 billion heap allocations, exhausting available memory. No public exploit code URL is provided, though SSVC classifies exploitation status as proof-of-concept; the vulnerability is not listed in CISA KEV, and EPSS at 0.01% (2nd percentile) confirms minimal observed exploitation activity.
Technical ContextAI
NanaZip (CPE: cpe:2.3:a:m2team:nanazip:*:*:*:*:*:*:*:*) is an open-source Windows file archiver derived from 7-Zip. The affected component is its littlefs filesystem image parser - littlefs being a lightweight filesystem designed for embedded systems. CWE-770 (Allocation of Resources Without Limits or Throttling) identifies the root cause: the Open method reads the 32-bit unsigned integer BlockCount directly from the littlefs superblock, which is fully attacker-controlled, then enters a loop iterating BlockCount times and allocating a file-path entry on the heap per iteration. Because no upper-bound ceiling is enforced and BlockCount is never validated against the actual byte size of the supplied image, setting BlockCount to the maximum 32-bit unsigned value (0xFFFFFFFF, approximately 4.29 billion) causes the allocator to be invoked billions of times. The minimal reproduction case is a 44-byte image, confirming the superblock parsing occurs before any file-size consistency check.
RemediationAI
Upgrade to NanaZip 6.0.1698.0 or later, which is confirmed as the fixed release by the vendor security advisory at https://github.com/M2Team/NanaZip/security/advisories/GHSA-7hqh-mq57-wjmq. If immediate upgrade is not possible, the most effective compensating control is to configure file-type associations and user policies to prevent NanaZip from being used to open archives from untrusted sources, since exploitation unconditionally requires a user to open a crafted littlefs image. Restricting which users or processes can invoke NanaZip on externally sourced files (e.g., via application allowlisting or file-open policy in managed environments) reduces exposure. No network-level controls apply given the local attack vector. There are no documented side effects to upgrading to 6.0.1698.0.
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 technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today