CVE-2026-39243 in decompress
Summary
by MITRE • 07/10/2026
decompress before 4.2.2 allows arbitrary hardlink creation during archive extraction, enabling file read disclosure and file corruption. When processing hardlink entries (type === 'link'), the x.linkname field from the archive is passed directly to fs.link() without validation (index.js line 113). An attacker can craft an archive with a hardlink entry whose linkname is an absolute path to any file on the same filesystem. This creates a hardlink inside the extraction directory that shares the same inode as the target file, enabling both reading and overwriting the original file's content. Hardlinks are limited to files on the same filesystem and cannot target directories.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 07/10/2026
The vulnerability in decompress versions prior to 4.2.2 represents a critical security flaw that enables arbitrary hardlink creation during archive extraction processes. This issue stems from insufficient input validation when handling hardlink entries within archive files, specifically affecting the x.linkname field processing. The technical implementation fails to validate or sanitize the linkname parameter before passing it to the underlying filesystem linking operation fs.link(). This oversight creates a significant attack surface where malicious actors can manipulate archive contents to establish hardlinks to arbitrary files on the same filesystem.
The operational impact of this vulnerability extends beyond simple file access violations to encompass both information disclosure and data corruption capabilities. When an attacker crafts an archive containing a hardlink entry with a malicious linkname parameter, the system creates a hardlink within the extraction directory that points to any file accessible within the same filesystem. This means that files that should remain protected can be accessed through the hardlink, potentially exposing sensitive data or allowing attackers to modify content in ways that bypass normal access controls. The vulnerability specifically affects type === 'link' entries in archive processing and operates at the filesystem level where the extraction occurs.
This security flaw aligns with CWE-22 known as "Improper Limitation of a Pathname to a Restricted Directory" and represents a direct violation of proper input validation practices essential for secure file operations. The vulnerability also maps to ATT&CK technique T1059.007 for "Command and Scripting Interpreter: JavaScript' when exploited through malicious archive content, and T1566.002 for "Phishing: Spearphishing Attachment" as attackers often deliver such exploits via compromised archive files. The root cause operates at the system call level where filesystem operations are performed without proper boundary checking or path validation.
The mitigation strategy requires implementing comprehensive input validation and sanitization of all linkname parameters during archive extraction processes. Specifically, the code should validate that linkname values do not contain absolute paths or traverse beyond the intended extraction directory boundaries. Additionally, implementing proper path resolution checks and ensuring that hardlink operations only occur within designated safe directories would prevent this vulnerability from being exploited. The fix should also consider implementing filesystem-level restrictions to prevent creation of hardlinks to files outside the target extraction scope while maintaining legitimate hardlink functionality for valid use cases.
The exploitation of this vulnerability demonstrates how seemingly simple file processing operations can create significant security implications when proper input validation is omitted. This issue highlights the importance of defensive programming practices and the need for comprehensive security testing of file handling operations, particularly in libraries that process untrusted data from external sources. The limited scope to same-filesystem targets does not diminish the severity, as attackers can still target any accessible files within the extraction environment's filesystem boundaries, potentially compromising system integrity and confidentiality through indirect access paths.