CVE-2026-42442 Overview
CVE-2026-42442 is a null pointer dereference vulnerability in NanaZip, an open source file archive utility for Windows. The flaw resides in the UFS/UFS2 filesystem image parser. Attackers trigger the issue by crafting a UFS image where the root inode (inode 2) is set to IFLNK (symlink) instead of IFDIR (directory). The parser treats the root inode as a directory without validating its type. When the symlink contains an embedded target with a small di_size, the directory data buffer is zero-length, causing a null pointer dereference on the first read. Versions from 5.0.1252.0 up to (but not including) 6.0.1698.0 are affected. The issue is tracked under [CWE-476].
Critical Impact
A user opening a malicious UFS archive in a vulnerable NanaZip build crashes the application, producing a local denial-of-service condition.
Affected Products
- NanaZip 5.0.1252.0 through 6.0.1697.x
- NanaZip UFS/UFS2 filesystem image parser component
- Fixed in NanaZip 6.0.1698.0
Discovery Timeline
- 2026-05-12 - CVE-2026-42442 published to NVD
- 2026-05-13 - Last updated in NVD database
Technical Details for CVE-2026-42442
Vulnerability Analysis
The vulnerability resides in NanaZip's UFS/UFS2 filesystem image handler. UFS (Unix File System) images use inode 2 as the root directory of the filesystem. NanaZip's parser assumes inode 2 always represents a directory entry and proceeds to enumerate directory children without type validation.
When an attacker sets the root inode type to IFLNK (symbolic link) and supplies a small di_size indicating an embedded symlink target, the parser allocates a zero-length directory data buffer. The parser then dereferences a null pointer on the first read attempt against that buffer, terminating the NanaZip process. The flaw is classified as CWE-476 (NULL Pointer Dereference).
Root Cause
The root cause is missing type validation on the UFS root inode. The parser does not check whether inode 2 has the IFDIR flag set before iterating directory entries. The mismatch between the declared symlink type and the parser's directory-handling code path produces an unallocated buffer that is later read without a guard.
Attack Vector
Exploitation requires local access and user interaction. An attacker must deliver a crafted UFS or UFS2 image (for example, as an email attachment or download) and convince the target user to open it in a vulnerable NanaZip build. The attack does not require authentication or elevated privileges. Impact is limited to availability of the NanaZip process; no confidentiality or integrity compromise is documented.
No public proof-of-concept code or exploitation in the wild has been reported. See the NanaZip GitHub Security Advisory GHSA-8r4x-fx3w-ph77 for upstream technical details.
Detection Methods for CVE-2026-42442
Indicators of Compromise
- Unexpected NanaZip process crashes or Windows Error Reporting (WER) entries referencing access violations in NanaZip modules
- Presence of UFS or UFS2 image files (.ufs, .img) delivered via email, download, or removable media from untrusted sources
- Crash dumps showing null pointer access during UFS root inode enumeration
Detection Strategies
- Inventory installed NanaZip versions across endpoints and flag any build below 6.0.1698.0
- Monitor file handler associations for UFS/UFS2 extensions mapped to NanaZip
- Alert on repeated NanaZip crashes originating from the same user or workstation, which may indicate testing of malicious archives
Monitoring Recommendations
- Forward Windows Application event log entries for NanaZip faulting modules to your SIEM
- Track download and email gateway telemetry for UFS filesystem image attachments
- Correlate NanaZip crash events with archive open operations to identify potentially malicious samples for retention and analysis
How to Mitigate CVE-2026-42442
Immediate Actions Required
- Upgrade NanaZip to version 6.0.1698.0 or later on all endpoints
- Identify and quarantine any UFS or UFS2 images received from untrusted sources pending review
- Communicate to users that opening unknown archive images carries denial-of-service risk on unpatched builds
Patch Information
The maintainers fixed the issue in NanaZip 6.0.1698.0 by adding type validation for the UFS root inode before treating it as a directory. Refer to the NanaZip GitHub Security Advisory GHSA-8r4x-fx3w-ph77 for commit details and release notes.
Workarounds
- Avoid opening UFS or UFS2 filesystem images from untrusted sources until NanaZip is upgraded
- Remove UFS/UFS2 file associations from NanaZip on endpoints that do not require this format
- Restrict NanaZip installations to currently supported versions through software inventory and allowlisting policies
# Example: list installed NanaZip version on Windows endpoints
Get-AppxPackage -Name "*NanaZip*" | Select-Object Name, Version
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
