CVE-2025-1744 is a critical memory safety flaw in radare2, the reverse engineering framework, scored 9.8. It affects versions before 5.9.9 and comes from zlib inflate code copied into radare2, which missed the upstream fix for CVE-2022-37434. Upgrade to radare2 5.9.9 or later, and avoid opening untrusted files on a machine you care about.
What's affected
radare2 is an open source toolkit used to analyse binaries. It ships copies of some third party code, and this CVE is about a copy that was behind its upstream.
- Product: radare2 (radareorg/radare2)
- Affected: before 5.9.9, per the CVE record
- Fixed: 5.9.9, per the record. The fix landed in radare2 pull request 23969, which was merged in February 2025.
- Severity: Critical, CVSS 9.8 in the record (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
- Known exploited (CISA KEV): no, the record's kev flag is false
The record states the issue as a buffer overflow in versions before 5.9.9 and gives few details. The pull request page is the best public description of the cause.
The pull request that fixed this describes a vulnerability in inflate() that was cloned from zlib but did not receive the security patch. The upstream fix, in zlib, covers a gzip header extra field: if the field was larger than the space the caller provided, and inflate() delivered the data across several calls, a buffer overflow of the provided space could occur.
How to check if you're exposed
Check the installed version on every machine that has radare2 or a tool that bundles it.
radare2 -v
r2 -v
If you installed through a package manager, check the package version and its changelog.
brew list --versions radare2
apt policy radare2
If you build from source, check the tag or commit you built from against the 5.9.9 release. Also look for tools that embed radare2 as a library, such as bindings used in analysis pipelines or sandboxes, because they carry their own copy.
The input is a file, so exposure depends on who gives your analysts files. A malware analysis box that opens samples is exactly the kind of place where a parser bug matters, although such machines should already be isolated.
What to do now
- Upgrade radare2 to 5.9.9 or later on analysis machines, CI jobs and containers.
- Rebuild any images that bundle radare2 and confirm the version inside them.
- Run analysis of untrusted files in a disposable virtual machine or container with no secrets and limited network access.
- Do not run analysis tools as root.
- Update any wrapper tools or language bindings that include radare2.
- Add radare2 to your software inventory so the next issue is easy to scope.
Why it matters
The weakness is memory corruption (CWE-787). The code parses a file format and writes or copies more data than the buffer can hold.
The lesson is about vendored code. When a project copies a library into its own tree, upstream fixes do not arrive on their own. The radare2 maintainer said as much in the pull request discussion: that is the risk of shipping third party code, and it took too long to be updated. If you also copy libraries into your own repositories, track the upstream advisories for them.
The record maps this to CWE-787 (Out-of-bounds Write).
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is CVE-2025-1744 exploited in the wild?
The record's CISA KEV flag is false and nothing in the record says it is being exploited.
Which radare2 version is fixed?
The record says versions before 5.9.9 are affected, so use 5.9.9 or later.
Sources
Last reviewed: 19 October 2026.
