# CVE-2026-8696: radareorg radare2 use-after-free in gdbr_pids_list

Source: https://junglewise.ai/threats/cve-2026-8696-radareorg-radare2-use-after-free-in-gdbr-pids-list  
Publisher: Junglewise Threat Intelligence, https://junglewise.ai/threats  
Published: 2026-05-15. Updated: 2026-05-15  
License: CC BY 4.0 with a link back

CVE-2026-8696 · Severity: high · CVSS 7.5 · Published 2026-05-15

radare2 is a popular open-source reverse engineering framework used by security researchers to analyze software. A memory corruption vulnerability in its GDB client component allows a malicious or compromised GDB server to crash the application or potentially execute unauthorized code. This could lead to a loss of availability during security analysis or a compromise of the researcher's workstation.

## Quick answers

**Is CVE-2026-8696 exploited in the wild?** No. Junglewise Threat Intelligence has no report of CVE-2026-8696 being exploited in the wild.

**How severe is CVE-2026-8696?** High severity, with a CVSS score of 7.5, published 15 May 2026.

**Which products and versions are affected?** radareorg radare2 <= 6.1.5.

**Is there a fix for CVE-2026-8696?** A patch was published on 2026-05-15: Fix committed to repository Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.

**How is CVE-2026-8696 attacked?** It is attacked over the network, in a software library.

**Am I affected by CVE-2026-8696?** Check whether anything you run is named in the advisory. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

## Technical details

A use-after-free (specifically a double-free) vulnerability exists in radare2 version 6.1.5 and earlier within the `gdbr_pids_list()` function of the GDB client core. The flaw is triggered when a remote GDB server sends a successful response to a `qfThreadInfo` request but subsequently causes a `qsThreadInfo` request to fail. In this error state, the `dpid` variable is not reset to NULL after being appended to the process list; the error handling path then attempts to free the `dpid` pointer twice—once individually and once as part of the list cleanup. This memory corruption can be exploited by a malicious GDB server to cause a denial of service (crash) or potentially achieve remote code execution. A fix has been committed to the radare2 repository to nullify the pointer after list insertion.

## Affected products

- radareorg radare2 <= 6.1.5

## Timeline

- 2026-04-16: disclosed: Issue reported on GitHub
- 2026-05-15: advisory: NVD publication date
- 2026-05-15: patched: Fix committed to repository

## References

- [https://github.com/radareorg/radare2/commit/c213ad6894a1eb9086ac8bf5fae35757e9e1683c](https://github.com/radareorg/radare2/commit/c213ad6894a1eb9086ac8bf5fae35757e9e1683c)
- [https://github.com/radareorg/radare2/issues/25836](https://github.com/radareorg/radare2/issues/25836)
- [https://www.vulncheck.com/advisories/radare2-use-after-free-via-gdbr-pids-list](https://www.vulncheck.com/advisories/radare2-use-after-free-via-gdbr-pids-list)