CVE-2026-8695: Radare2 Use-After-Free Vulnerability

CVE-2026-8695 Overview

CVE-2026-8695 is a use-after-free vulnerability [CWE-416] in radare2 version 6.1.5. The flaw resides in the gdbr_threads_list() function within the GDB remote protocol client. Remote attackers can trigger memory corruption by sending a valid qfThreadInfo response followed by a malformed qsThreadInfo response. Exploitation requires the radare2 user to connect to an attacker-controlled GDB remote server. Successful exploitation leads to denial of service and may allow code execution through manipulation of the thread list processing routine.

Critical Impact
A malicious GDB remote server can corrupt radare2 memory during thread enumeration, causing crashes and creating conditions that may enable arbitrary code execution in the debugger process.

Affected Products

radare2 version 6.1.5
Builds of radare2 that include the GDB remote debugging client (shlr/gdb/src/gdbclient/core.c)
Distributions and toolchains bundling vulnerable radare2 versions

Discovery Timeline

2026-05-15 - CVE-2026-8695 published to the National Vulnerability Database
2026-05-18 - Last updated in NVD database
2026-05-21 - EPSS scoring data published

Technical Details for CVE-2026-8695

Vulnerability Analysis

The vulnerability exists in radare2's GDB remote serial protocol client. The function gdbr_threads_list() enumerates remote threads by issuing two sequential queries: qfThreadInfo (first thread) and qsThreadInfo (subsequent threads). The implementation parses the response into RDebugPid structures and appends them to a thread list. A malformed qsThreadInfo response triggers reuse of a pointer (dpid) after its referenced memory has already been freed or transferred to the list. Attackers control the timing and contents of the malicious response, giving direct influence over the freed object's reuse path.

Root Cause

The root cause is failure to reset the dpid pointer after appending it to the thread list. When subsequent parsing iterations encounter unexpected input, the stale pointer is dereferenced or freed again. The upstream commit c213ad6894a1eb9086ac8bf5fae35757e9e1683c resolves this by setting dpid = NULL immediately after r_list_append(), preventing reuse of the transferred reference.

Attack Vector

Exploitation requires a victim running radare2 to connect to an attacker-controlled GDB remote server, for example via r2 -d gdb://attacker:port. The attacker returns a valid qfThreadInfo response to seed the thread list, then returns a malformed qsThreadInfo response to trigger the use-after-free during continued parsing. No authentication is required on the radare2 client side beyond the user initiating the debugging session.

// Patch excerpt from shlr/gdb/src/gdbclient/core.c
// Commit c213ad6894a1eb9086ac8bf5fae35757e9e1683c
 			dpid->runnable = true;
 			dpid->status = R_DBG_PROC_STOP;
 			r_list_append (list, dpid);
+			dpid = NULL;
 			ptr = ptr2;
 		}
 		if (send_msg (g, "qsThreadInfo") < 0 || read_packet (g, false) < 0

Source: radare2 commit c213ad6. The fix nullifies the local pointer after ownership transfer, eliminating the dangling reference that drives the use-after-free.

Detection Methods for CVE-2026-8695

Indicators of Compromise

Radare2 process crashes with SIGSEGV or heap corruption signatures during GDB remote sessions
Outbound TCP connections from analyst workstations to untrusted hosts on GDB server ports such as 1234, 2345, or 9999
Core dumps from r2, radare2, or rarun2 referencing gdbr_threads_list or r_list_append in the stack trace

Detection Strategies

Inspect endpoint telemetry for radare2 or r2 invocations using gdb:// URIs pointing to external or non-corporate IP addresses
Monitor reverse engineering and malware analysis hosts for unexpected child process termination of radare2 binaries
Use AddressSanitizer or Valgrind in lab environments to confirm use-after-free conditions when analyzing untrusted GDB stubs

Monitoring Recommendations

Track installed radare2 versions across analyst endpoints and flag systems pinned to 6.1.5 or earlier
Alert on outbound connections from analysis workstations to GDB remote ports outside approved lab networks
Capture and review crash artifacts from analysis tooling to identify repeated faults in shlr/gdb code paths

How to Mitigate CVE-2026-8695

Immediate Actions Required

Upgrade radare2 to a build that includes commit c213ad6894a1eb9086ac8bf5fae35757e9e1683c or later
Avoid connecting radare2 to GDB remote stubs hosted on untrusted infrastructure until patched
Isolate malware analysis workstations on segmented networks that restrict outbound traffic to vetted destinations

Patch Information

The issue is fixed in the radare2 source tree by commit c213ad6, which addresses GitHub Issue #25835 and GitHub Issue #25836. Additional context is available in the VulnCheck advisory. Rebuild from a patched commit or install distribution packages that incorporate the fix.

Workarounds

Do not use the gdb:// debugger backend in radare2 against untrusted remote targets
Run radare2 inside a disposable virtual machine or container without access to sensitive credentials or networks
Apply host firewall rules that block outbound traffic from radare2 binaries to non-approved GDB server endpoints

bash

# Verify installed radare2 version and rebuild from a patched source tree
r2 -v
git clone https://github.com/radareorg/radare2.git
cd radare2
git checkout c213ad6894a1eb9086ac8bf5fae35757e9e1683c
sys/install.sh