LowPublic exploit

Memory Exhaustion in NanaZip UFS/FFS Image Handler

IdentifiersCVE-2026-55781CWE-770

CVE-2026-55781 is a denial-of-service vulnerability in NanaZip prior to version 6.5.1749.0 affecting the UFS and FFS image handler implemented in NanaZip.Codecs.Archive.Ufs.cpp. The vulnerable code validates the filesystem superblock block size only against a minimum lower bound and fails to properly validate the filesystem fragment size field. As a result, attacker-controlled 32-bit values from a crafted UFS image can propagate into allocation size calculations for indirect-block handling, directory processing, and extraction buffers. A maliciously crafted small filesystem image can therefore trigger extremely large memory allocations during archive open or extraction operations, leading to resource exhaustion and abnormal process termination.

For your environment

Are you exposed to this one?

Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.

Start free trial

ANALYST BRIEF

Impact, mitigation & remediation

What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.

Impact

What an attacker gets, and what they’ve been doing with it.

Successful exploitation can cause NanaZip to allocate multi-gigabyte buffers based on attacker-controlled metadata, resulting in memory exhaustion, application instability, or process termination. The available information indicates a denial-of-service condition rather than code execution or privilege escalation.

Mitigation

If you can’t patch tonight, do this now.

Until patched versions are deployed, avoid opening or extracting untrusted UFS or FFS filesystem images with affected NanaZip versions. Restrict handling of attacker-supplied archive and filesystem image content in user workflows, sandbox archive processing where feasible, and apply resource limits or monitoring to reduce the operational impact of memory-exhaustion conditions.

Remediation

Patch, then assume compromise.

Upgrade NanaZip to version 6.5.1749.0 or later, which fixes the improper validation in the UFS and FFS image handler. Remediation requires enforcing correct bounds and consistency checks on filesystem metadata fields, including fragment size values used in allocation calculations.

PUBLIC EXPLOITS

Exploits

2 valid exploits after Mallory filtered fakes, detection scripts, and README-only repos.

VALID 2 / 2 TOTALView more in app

CVE-2026-55781-pocMaturityPoCVerified exploit

This three-file repository contains a standalone Python proof of concept, an Apache-2.0 license, and documentation for CVE-2026-55781. The main script, CVE-2026-55781-poc.py, constructs a 66,912-byte UFS2 image entirely in memory and writes it to a local file. It places a UFS2 superblock at offset 65536 and a root inode at offset 512. The malicious fields are fs_bsize=0x40000000 and root di_size=0x10000000000; together they are intended to pass the parser's lower-bound checks and force the indirect-block allocation path. The verify() function reopens only the local output file and validates the encoded magic, block size, inode mode, and oversized inode size. The code makes no network requests, launches no subprocesses, and contains no shellcode or code-execution payload. Exploitation requires opening the generated image in an affected NanaZip build, where it is intended to cause roughly 3 GiB of memory allocation and denial of service. The README states the PoC was derived through static analysis and was not executed against a live NanaZip instance. It also refers to the script as poc.py in its usage example, while the repository's actual script filename is CVE-2026-55781-poc.py.

yzy0okrkv1hngo0rDisclosed Sep 17, 2026pythonmarkdownfile

CVE-2026-55781-pocMaturityPoCVerified exploit

This three-file repository contains one standalone Python proof-of-concept, a README, and an Apache-2.0 license. CVE-2026-55781-poc.py constructs a minimally sized UFS2 image rather than interacting with a network service or invoking NanaZip itself. It writes a root inode at offset 512 and a UFS2 superblock at offset 65536. The image uses a valid UFS2 magic value and directory inode mode, but supplies a 1-GiB fs_bsize and a 1-TiB root inode size. These values satisfy the parser's stated lower-bound checks while forcing indirect-block processing, where vulnerable NanaZip builds allegedly allocate multiple buffers sized from fs_bsize. The script then locally re-parses its own output to validate the crafted field offsets and conditions. There are no network requests, subprocesses, persistence mechanisms, shell payloads, or remote-control capabilities. The README identifies the issue as CWE-789 affecting NanaZip through 6.5 Preview 6.5.1742.0 on Windows and states that 6.5.1749.0 fixes it. The PoC is appropriately classified as a file-based denial-of-service proof of concept; its README notes it was derived from static analysis and was not executed against a live vulnerable build.

g17hubH4ckDisclosed Sep 17, 2026pythonmarkdownfile

ACTIVITY FEED

Recent activity

4 sources tracked across advisories and community write-ups. News coverage will land here when it surfaces.

4 SOURCESView more in app

No news coverage yet. Advisories and community discussion only.

What this page doesn’t show

The version that knows your environment.

This page is what’s public. Mallory adds the parts that aren’t: which of your assets are affected, which adversaries are exploiting it right now, which detections to deploy, and what to do tonight.

Start free trial

Exposure mapping

Query your assets running an affected version, and investigate the blast radius.

Threat actor evidence

Every observed campaign linking this CVE to a named adversary.

Associated malware

Malware families riding this exploit, with evidence and IOCs.

Detection signatures

YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.

Vendor-by-vendor mapping

Cross-references every affected SKU, including bundled OEM variants.

Social activity4