Hi,
The following vulnerabilities were published for radare2.
CVE-2026-81878[0]:
| radare2 is a UNIX-like reverse engineering framework and command-
| line toolset. Prior to 6.2.0, radare2's CPython bytecode .pyc
| marshal parser was vulnerable because the CPython marshal readers
| accepted a 32-bit string length without rejecting values that
| overflow the size-plus-one allocation. The vulnerability is
| triggered by opening or inspecting a crafted .pyc file through r2 or
| rabin2. A length of 0xffffffff wrapped the allocation to zero before
| the common byte reader wrote attacker-controlled data and fill bytes
| beyond the heap allocation. This can cause heap memory corruption
| and denial of service; arbitrary code execution is possible but has
| not been demonstrated. This issue is fixed in version 6.2.0.
CVE-2026-81879[1]:
| 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.
CVE-2026-81880[2]:
| radare2 is a UNIX-like reverse engineering framework and command-
| line toolset. Prior to 6.2.0, radare2's Apple Preferred Executable
| Format loader was vulnerable because the PEF loader accepted
| relocSecCount values that were not bounded by the number of sections
| or complete relocation records in the input. The vulnerability is
| triggered by normal binary-format auto-detection of a small crafted
| Apple PEF file. The loader could perform up to 268,435,456
| relocation-section iterations and repeated buffer operations after
| record offsets passed the end of the file. This can cause denial of
| service through excessive CPU consumption and prolonged processing.
| This issue is fixed in version 6.2.0.
CVE-2026-81881[3]:
| radare2 is a UNIX-like reverse engineering framework and command-
| line toolset. Prior to 6.2.0, radare2's Mach-O Swift field-metadata
| parser was vulnerable because a relative Swift field pointer could
| be lower than the field-metadata section base, making subtraction
| produce a negative logical index. The vulnerability is triggered by
| parsing Swift type and class metadata from a crafted Mach-O file.
| The derived index was used to read four bytes immediately before the
| allocated field-metadata buffer. This can cause incorrect metadata
| processing or process termination; no attacker-observable memory
| disclosure has been demonstrated. This issue is fixed in version
| 6.2.0.
CVE-2026-81882[4]:
| radare2 is a UNIX-like reverse engineering framework and command-
| line toolset. Prior to 6.2.0, radare2's binary property-list Unicode
| parser was vulnerable because the binary-property-list Unicode
| parser underallocated an uninitialized UTF-8 destination and did not
| guarantee NUL termination. The vulnerability is triggered by running
| the explicit pFB or pFBj commands on untrusted binary property-list
| data. The json encoder treated the converted data as a nul-
| terminated c string and could continue reading beyond the
| allocation. This can cause disclosure of uninitialized or adjacent
| heap contents in JSON output and possible process termination. This
| issue is fixed in version 6.2.0.
CVE-2026-81883[5]:
| radare2 is a UNIX-like reverse engineering framework and command-
| line toolset. Prior to 6.2.0, radare2's Lua 5.3 bytecode function
| parser was vulnerable because the Lua 5.3 bytecode function parser
| read fixed function-metadata fields immediately after a function-
| name string without checking the remaining buffer length. The
| vulnerability is triggered by opening or inspecting a crafted Lua
| 5.3 bytecode file whose function-name string ends at the input-
| buffer boundary. The parser read two integers and three one-byte
| fields beyond the allocated input buffer. This can cause invalid
| parser results or process termination; no attacker-observable memory
| disclosure has been demonstrated. This issue is fixed in version
| 6.2.0.
CVE-2026-81884[6]:
| radare2 is a UNIX-like reverse engineering framework and command-
| line toolset. Prior to 6.2.0, radare2's Mach-O LC_DATA_IN_CODE
| parser was vulnerable because the Mach-O LC_DATA_IN_CODE parser
| trusted dataoff and datasize and allowed a final partial record to
| be processed. The vulnerability is triggered by opening a crafted
| Mach-O file while the non-default bin.verbose option is enabled.
| When datasize was not a multiple of data_in_code_entry, the last
| iteration read beyond the allocated buffer. This can cause a heap
| out-of-bounds read and possible process termination; no attacker-
| observable memory disclosure has been demonstrated. This issue is
| fixed in version 6.2.0.
CVE-2026-81885[7]:
| radare2 is a UNIX-like reverse engineering framework and command-
| line toolset. Prior to 6.2.0, radare2's NE relocation fixup-chain
| parser was vulnerable because the NE relocation parser followed
| fixup chains without an active iteration limit or cycle detection.
| The vulnerability is triggered by opening a crafted NE executable
| whose in-bounds relocation entry points back to itself instead of
| reaching 0xffff. The parser repeatedly processed the same relocation
| and allocated another relocation object on each iteration. This can
| cause denial of service through continuous CPU and memory
| consumption. This issue is fixed in version 6.2.0.
CVE-2026-81886[8]:
| radare2 is a UNIX-like reverse engineering framework and command-
| line toolset. Prior to 6.2.0, radare2's Windows 64-bit crash-dump
| dmp64 parser was vulnerable because the Windows dmp64 parser used an
| input-controlled physical-memory-run PageCount directly as the bound
| of a per-page allocation loop. The vulnerability is triggered by
| opening a small crafted full-memory Windows crash dump. The parser
| repeatedly allocated and appended page descriptors without
| validating the count against the dump size. This can cause denial of
| service through excessive memory consumption and processing time.
| This issue is fixed in version 6.2.0.
If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
For further information see:
[0] https://security-tracker.debian.org/tracker/CVE-2026-81878
https://www.cve.org/CVERecord?id=CVE-2026-81878
[1] https://security-tracker.debian.org/tracker/CVE-2026-81879
https://www.cve.org/CVERecord?id=CVE-2026-81879
[2] https://security-tracker.debian.org/tracker/CVE-2026-81880
https://www.cve.org/CVERecord?id=CVE-2026-81880
[3] https://security-tracker.debian.org/tracker/CVE-2026-81881
https://www.cve.org/CVERecord?id=CVE-2026-81881
[4] https://security-tracker.debian.org/tracker/CVE-2026-81882
https://www.cve.org/CVERecord?id=CVE-2026-81882
[5] https://security-tracker.debian.org/tracker/CVE-2026-81883
https://www.cve.org/CVERecord?id=CVE-2026-81883
[6] https://security-tracker.debian.org/tracker/CVE-2026-81884
https://www.cve.org/CVERecord?id=CVE-2026-81884
[7] https://security-tracker.debian.org/tracker/CVE-2026-81885
https://www.cve.org/CVERecord?id=CVE-2026-81885
[8] https://security-tracker.debian.org/tracker/CVE-2026-81886
https://www.cve.org/CVERecord?id=CVE-2026-81886
Please adjust the affected versions in the BTS as needed.
Regards,
Salvatore