CVE-2026-110716 in unshield
Summary
by MITRE • 10/14/2026
unshield through 1.6.2 contains a heap out-of-bounds read vulnerability in unshield_get_file_table() that allows attackers to read past heap allocations via unchecked cabinet header offsets. Attackers can supply a crafted InstallShield cabinet with out-of-range file_table_offset or large file counts to crash the unshield tool or library consumers.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/14/2026
The vulnerability identified in Unshield versions through 1.6.2 represents a critical memory safety flaw located within the core parsing logic of the software, specifically inside the unshield_get_file_table function. This component is responsible for interpreting InstallShield cabinet files, which are compressed archive formats commonly used by Windows-based installers to bundle application data and installation scripts. The root cause of this vulnerability lies in the failure to perform adequate bounds checking on header offsets extracted from the cabinet file structure. When Unshield processes a cabinet file, it reads various metadata fields, including the offset pointing to the file table where information about contained files is stored. In vulnerable versions, the application does not validate whether these offset values fall within the boundaries of the allocated memory buffer or if they correspond to valid data structures before proceeding with further processing operations.
This lack of validation allows an attacker who can supply a maliciously crafted InstallShield cabinet file to manipulate the internal state of the parser. By setting the file_table_offset field to an out-of-range value, such as pointing beyond the end of the allocated heap memory or into unmapped regions, the application attempts to read data from invalid addresses. Similarly, specifying an excessively large number of files can cause integer overflows during array indexing calculations, leading to access violations outside the intended buffer boundaries. The immediate technical consequence is a heap out-of-bounds read operation. This type of vulnerability falls squarely under CWE-125, which describes Out-of-bounds Read, as it involves accessing memory locations that are not part of the allocated object or region.
The operational impact of this flaw extends beyond simple application crashes. While an immediate denial of service is a likely outcome when the operating system detects illegal memory access and terminates the process, heap-based out-of-bounds reads can also lead to information disclosure. Depending on the specific implementation details and the state of the heap at the time of exploitation, an attacker might be able to read sensitive data stored in adjacent memory regions, such as pointers, cryptographic keys, or other application-specific secrets. This capability aligns with ATT&CK technique T1083, which covers File and Directory Discovery, although in this context it is more accurately described as a mechanism for information leakage rather than active discovery of system files. The vulnerability affects not only the standalone unshield command-line tool but also any software libraries or applications that integrate Unshield to parse InstallShield archives, thereby expanding the potential attack surface significantly across various enterprise and consumer environments.
Mitigation strategies must focus on both immediate remediation and long-term defensive coding practices. The primary solution is to upgrade Unshield to version 1.6.3 or later, where this specific bounds checking issue has been addressed by developers implementing strict validation of header fields before memory access occurs. For organizations unable to immediately patch their systems, deploying input validation filters at the network perimeter can help block maliciously crafted cabinet files from reaching vulnerable components. Additionally, enabling heap protection mechanisms such as Address Space Layout Randomization (ASLR) and Data Execution Prevention (DEP) on affected systems can mitigate the risk of exploitation by making it more difficult for attackers to predict memory layouts or execute arbitrary code following a crash. Developers integrating Unshield should also consider implementing sandboxing techniques to limit the potential impact if a vulnerability is present in their specific build configuration, ensuring that even if an out-of-bounds read occurs, the blast radius remains contained within isolated processes rather than compromising the entire host system.