CVE-2026-81886: radare2 Windows Crash-Dump Parser DoS Flaw

CVE-2026-81886 Overview

CVE-2026-81886 affects radare2, a UNIX-like reverse engineering framework and command-line toolset. The vulnerability resides in the Windows 64-bit crash-dump (dmp64) parser in versions prior to 6.2.0. The parser uses an input-controlled physical-memory-run PageCount field directly as the bound of a per-page allocation loop, without validating the value against the actual dump size. Opening a small crafted full-memory Windows crash dump triggers repeated allocation and appending of page descriptors, leading to excessive memory consumption and processing time. The issue is tracked under CWE-770: Allocation of Resources Without Limits or Throttling and is fixed in radare2 version 6.2.0.

Critical Impact
A crafted Windows crash dump file can exhaust memory and CPU resources on any host that opens it with a vulnerable radare2 build, disrupting reverse engineering and malware analysis workflows.

Affected Products

radare2 versions prior to 6.2.0
Windows 64-bit crash-dump (dmp64) parser component
Reverse engineering environments and analysis pipelines that ingest untrusted .dmp files

Discovery Timeline

2026-09-22 - CVE-2026-81886 published to the National Vulnerability Database
2026-09-23 - Last updated in NVD database

Technical Details for CVE-2026-81886

Vulnerability Analysis

The flaw lives in radare2's parser for Windows 64-bit full-memory crash dumps. Windows crash dumps describe physical memory using an array of physical-memory-run structures, each containing a PageCount field. The dmp64 parser reads this attacker-controlled value and uses it directly as the iteration bound for a loop that allocates and appends a page descriptor per iteration. Because no upper bound is enforced and the value is not cross-checked against the on-disk dump size, a small file can declare an arbitrarily large page count. The parser then performs sustained allocations and list appends until the host runs out of memory or the analyst kills the process.

Root Cause

The root cause is missing input validation on a length field consumed from an untrusted file, classified as CWE-770. The parser trusts the run's PageCount without sanity-checking it against the file size, remaining bytes, or a reasonable upper bound. This is a classic resource-exhaustion pattern in binary format parsers.

Attack Vector

Exploitation requires local access with user interaction: the victim must open a crafted dmp64 file in radare2. The attack yields no confidentiality or integrity impact, only availability loss on the analyst's machine. Realistic delivery scenarios include triage of dumps supplied through malware analysis exchanges, incident-response file drops, or shared research repositories.

No public proof-of-concept exploit is listed in the advisory. Technical details are available in the radare2 security advisory GHSA-3xrx-wh64-8xr8, the fix commit a7519fdb, and pull request #26180.

Detection Methods for CVE-2026-81886

Indicators of Compromise

radare2 processes consuming abnormally large amounts of memory shortly after opening a .dmp file
Analyst workstations exhibiting sudden swap pressure or out-of-memory conditions during crash-dump triage
Small crash-dump files (kilobytes to a few megabytes) that declare physical memory runs describing gigabytes of pages

Detection Strategies

Inventory installed radare2 versions across analyst workstations and CI pipelines, flagging any build below 6.2.0
Inspect suspicious dmp64 samples with a size-aware parser or file/custom scripts to compare declared PageCount values against on-disk size
Sandbox untrusted crash dumps in resource-constrained containers before opening them in radare2

Monitoring Recommendations

Alert on radare2 process memory growth exceeding a defined threshold (for example, 4 GB) within seconds of file open
Track OOM-killer events on analyst hosts and correlate with recent r2/radare2 command executions
Log file provenance for .dmp samples imported into analysis environments to enable post-incident review

How to Mitigate CVE-2026-81886

Immediate Actions Required

Upgrade radare2 to version 6.2.0 or later on all analyst workstations, servers, and automation pipelines
Avoid opening untrusted Windows crash dumps in unpatched radare2 instances
Run crash-dump triage inside isolated virtual machines or containers with capped memory limits

Patch Information

The issue is fixed in radare2 release 6.2.0. The remediation validates the physical-memory-run PageCount against the dump size before allocating per-page descriptors. See the upstream fix commit and the tracking issue #26224 for implementation details.

Workarounds

Restrict radare2 execution to sandboxes with hard memory ceilings (for example, systemd-run --user -p MemoryMax=4G)
Pre-screen .dmp files with a lightweight validator that rejects samples whose declared page counts exceed the file size
Disable automated ingestion of dmp64 files in shared analysis pipelines until all workers are running radare2 6.2.0

bash

# Verify installed radare2 version and enforce a memory ceiling when analyzing untrusted dumps
r2 -v

# Linux: run radare2 with a hard memory cap via systemd-run
systemd-run --user --scope -p MemoryMax=4G -p MemorySwapMax=0 \
  r2 -A /path/to/untrusted.dmp