CVE-2026-81879 in radare2
Summary
by MITRE • 09/22/2026
radare2 is a UNIX-like reverse engineering framework and command-line toolset. Prior to 6.2.0, radare2's ELF PN_XNUM handling was vulnerable because the ELF parser allocated the program-header array using the resolved PN_XNUM count but several consumers still iterated with the original e_phnum value of 65535. The vulnerability is triggered by processing a crafted ELF file with e_phnum = 0xffff and a much smaller resolved count in shdr[0].sh_info. Consumers iterated beyond the allocated program-header array. This can cause a heap out-of-bounds read and process termination, resulting in denial of service; memory disclosure and code execution have not been demonstrated. This issue is fixed in version 6.2.0.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/22/2026
The vulnerability identified in radare2 prior to version 6.2.0 represents a critical flaw within the ELF parsing subsystem, specifically concerning the handling of extended program header numbers as defined by the Executable and Linkable Format specification. Radare2 is widely utilized for reverse engineering and binary analysis, making its robustness essential for security professionals who rely on it to dissect complex binaries without crashing or producing erroneous results. The core issue stems from a discrepancy between how the ELF parser resolves the number of program headers and how subsequent components iterate over them. In standard ELF files, the e_phnum field indicates the number of entries in the program header table. However, when this value reaches 65535 (0xffff), it serves as an indicator that the actual count is stored in the sh_info field of the first section header, a mechanism known as PN_XNUM handling designed to support files with more than 65535 headers.
The technical flaw arises because while the parser correctly allocates memory for the program-header array based on the resolved PN_XNUM value from the section header, several consumer modules within radare2 continue to use the original e_phnum value of 65535 as their iteration limit. This creates a situation where the code attempts to access elements in an array that is significantly smaller than expected if the actual count derived from sh_info is low. For instance, if a crafted ELF file specifies e_phnum as 0xffff but indicates via shdr[0].sh_info that there are only ten program headers, the parser allocates space for just those ten entries. However, the consumer logic proceeds to iterate through all 65535 slots implied by the initial header value. This mismatch leads directly to a heap out-of-bounds read condition, as the code attempts to dereference memory addresses that lie beyond the allocated buffer boundaries.
From an operational impact perspective, this vulnerability primarily results in denial of service due to process termination caused by segmentation faults or similar runtime errors when accessing invalid memory locations. While theoretical implications for information disclosure and arbitrary code execution exist given the nature of out-of-bounds reads, no such exploits have been demonstrated against radare2 specifically through this vector. The primary risk remains stability during analysis tasks, which can disrupt workflows in automated scanning pipelines or interactive debugging sessions where unexpected crashes interrupt progress. This aligns with CWE-125, Out-of-bounds Read, as the application accesses memory beyond its intended boundary without proper validation of array indices against actual allocation sizes.
The vulnerability is categorized under ATT&CK technique T1083, File and Directory Discovery, in the context that radare2 is often used to enumerate and analyze file structures within binaries. Although not a direct exploitation of discovery for lateral movement, the misuse of metadata parsing during analysis reflects weaknesses in input validation common in security tools themselves. Mitigation requires upgrading to version 6.2.0 or later, where the developers have corrected the iteration logic to ensure that consumers respect the resolved PN_XNUM count rather than relying on the potentially misleading e_phnum value when it indicates extended numbering is in use. Additionally, users processing untrusted ELF files should employ sandboxed environments to contain potential crashes until updates are applied across all systems utilizing radare2 for binary analysis tasks.