CVE-2026-8696: Radare2 Use-After-Free RCE Vulnerability

CVE-2026-8696 Overview

CVE-2026-8696 is a use-after-free vulnerability [CWE-416] in radare2 version 6.1.5. The flaw resides in the gdbr_pids_list() function inside the GDB client core. A malicious GDB server can send malformed thread information responses that trigger double-free memory corruption in the client. Remote attackers can cause denial of service and may achieve arbitrary code execution within the radare2 process. The issue occurs when qsThreadInfo fails after qfThreadInfo has already allocated RDebugPid structures, and the error path mishandles cleanup of the list.

Critical Impact

Remote attackers operating a malicious GDB server can crash radare2 clients or potentially execute arbitrary code by returning crafted thread information replies.

Affected Products

• radare2 version 6.1.5
• radare2 GDB client core (gdbr_pids_list() code path)
• Tooling and forks that embed the affected radare2 GDB remote debugging library

Discovery Timeline

• 2026-05-15 - CVE-2026-8696 published to the National Vulnerability Database (NVD)
• 2026-05-19 - Last updated in NVD database

Technical Details for CVE-2026-8696

Vulnerability Analysis

The vulnerability is a use-after-free [CWE-416] in radare2's GDB remote debugging client. radare2 queries thread information from a remote GDB server using the qfThreadInfo and qsThreadInfo packet pair. On a successful qfThreadInfo response, the client allocates and populates RDebugPid structures and links them into a list. When the subsequent qsThreadInfo request fails or returns a malformed response, the error path attempts to release the list. The cleanup logic frees structures that are later freed again, producing double-free memory corruption.

Because radare2 frequently connects to user-supplied or untrusted debug targets, the attacker need only control the GDB server endpoint. The condition is reachable without authentication and without user interaction beyond initiating a debug session against the attacker-controlled target.

Root Cause

The root cause is improper ownership tracking of RDebugPid entries between the two-stage qfThreadInfo/qsThreadInfo exchange. When qsThreadInfo parsing fails, the error handler does not null out or detach pointers that have already been transferred to the result list, allowing the same heap object to be freed twice. The upstream fix is recorded in commit c213ad6894a1eb9086ac8bf5fae35757e9e1683c.

Attack Vector

Exploitation requires a victim to attach radare2 to a malicious or compromised GDB server (for example, via gdb://host:port or gdb-remote). The attacker server returns a valid qfThreadInfo reply followed by a malformed qsThreadInfo reply that forces the client into its error cleanup path. The resulting double-free corrupts heap metadata, producing a crash and, depending on the allocator state, potentially permitting code execution within the radare2 process.

No verified public exploit code is available. See the VulnCheck advisory for radare2 and the GitHub issue discussion for technical details.

Detection Methods for CVE-2026-8696

Indicators of Compromise

• Unexpected crashes of radare2, r2, or rarun2 processes with heap corruption signatures such as glibc double free or corruption aborts.
• Core dumps referencing gdbr_pids_list, gdbr_threads_list, or nearby frames in the radare2 GDB client.
• Outbound connections from analyst workstations to untrusted hosts on GDB remote serial protocol ports (commonly TCP/1234, TCP/2345, or arbitrary attacker-controlled ports).

Detection Strategies

• Monitor for radare2 invocations using gdb://, gdb-remote, or -d gdb arguments that target external or untrusted endpoints.
• Enable AddressSanitizer or glibc MALLOC_CHECK_=3 in test environments to catch double-free conditions in radare2 GDB sessions.
• Inventory installed radare2 binaries and flag versions at or below 6.1.5 that lack commit c213ad6.

Monitoring Recommendations

• Log process execution and command-line arguments for reverse engineering tools on analyst endpoints and correlate against outbound network connections.
• Alert on unexpected child process creation or memory protection changes spawned from radare2 processes that have attached to remote GDB targets.
• Capture and retain crash dumps from radare2 to support triage and to distinguish benign instability from exploitation attempts.

How to Mitigate CVE-2026-8696

Immediate Actions Required

• Upgrade radare2 to a release that includes commit c213ad6894a1eb9086ac8bf5fae35757e9e1683c or rebuild from a patched source tree.
• Restrict use of radare2's GDB remote debugging features to trusted, authenticated debug targets only.
• Audit analyst workstations and CI pipelines that automate radare2 against remote targets to confirm patched versions are in use.

Patch Information

The radare2 project addressed the double-free by correcting ownership handling in the qfThreadInfo/qsThreadInfo cleanup path. The fix is published in upstream commit c213ad6894a1eb9086ac8bf5fae35757e9e1683c. Users should consume releases built after this commit. Distributions packaging radare2 6.1.5 should backport the patch.

Workarounds

• Avoid connecting radare2 to GDB servers that are not fully trusted, including unknown remote hosts and shared lab infrastructure.
• Run radare2 inside a sandbox or container with no sensitive credentials and minimal filesystem access when remote debugging is required.
• Use network egress controls to prevent analyst workstations from initiating GDB remote sessions to arbitrary internet hosts.

# Build a patched radare2 from source
git clone https://github.com/radareorg/radare2.git
cd radare2
git checkout c213ad6894a1eb9086ac8bf5fae35757e9e1683c
sys/install.sh

# Verify installed version
r2 -v