CVE-2026-45324: Rizin Double Free Vulnerability in byte_pattern_search()

Technical summary

CVE-2026-45324 is a double free vulnerability in librz/core/cmd/cmd_search.c within the byte_pattern_search() function. The root cause is improper pointer ownership declaration, leading to the same memory being deallocated twice during execution. Double free conditions can corrupt heap metadata and may enable denial of service or, in specific circumstances, code execution. The issue was remediated in commit 045fff363b42b8a6dda8ad5229c29ec3267e7dbe.

Business impact

For organizations using Rizin in security research, malware analysis, or vulnerability assessment workflows, this vulnerability poses a limited but real risk of tool instability. Exploitation would likely result in application crashes or temporary unavailability of the reverse engineering capability, disrupting analysis tasks. Since exploitation requires physical access and user interaction, the practical risk to production systems is minimal. Teams relying on Rizin for critical analysis pipelines should plan updates to avoid unexpected downtime.

Affected systems

Rizin installations are affected prior to the commit 045fff363b42b8a6dda8ad5229c29ec3267e7dbe. No specific version numbers are disclosed in the advisory; security teams should consult the Rizin project repository and official releases to identify the patched version corresponding to this commit hash. If your organization maintains a Rizin installation, verify the current build commit and update accordingly.

Exploitability

Exploitation is constrained by the attack vector profile (CVSS:3.1/AV:P/AC:H/PR:L/UI:R/S:C). The vulnerability requires physical access to the system, local privilege to some degree, relatively high complexity of conditions, and user interaction. These factors combine to create a low practical exploitation likelihood in typical security operations environments. The vulnerability is not tracked on the KEV (Known Exploited Vulnerabilities) catalog, indicating no evidence of active exploitation in the wild.

Remediation

Update Rizin to a version or build incorporating commit 045fff363b42b8a6dda8ad5229c29ec3267e7dbe or later. Consult the Rizin project's official release notes and repository to identify the appropriate patched version for your deployment. For organizations building Rizin from source, pull the latest main branch or apply the specific commit. Standard software update processes should suffice; no special precautions are necessary.

Patch guidance

Verify the Rizin project's official repository and releases to identify the version number corresponding to or after commit 045fff363b42b8a6dda8ad5229c29ec3267e7dbe. Apply the update through your standard package management or build process. If building from source, update to a commit at or after the fix commit. Test patched builds in a non-production environment to confirm tool functionality remains intact before deployment to analysis infrastructure.

Detection guidance

Operationally, detection is challenging since exploitation requires local interaction and the vulnerability manifests as application crashes rather than external network signals. Monitor Rizin process logs and system behavior for unexpected terminations during search operations. Version auditing is the most practical detection approach: scan your environment for Rizin installations and compare build information or commit hashes against the known-safe commit 045fff363b42b8a6dda8ad5229c29ec3267e7dbe. Binary analysis of Rizin executables may also reveal whether the vulnerable code path is present.

Why prioritize this

This vulnerability merits routine patching but does not require emergency response. The CVSS 3.3 (LOW) score reflects the stringent prerequisites: physical access, local privileges, user interaction, and high attack complexity. It is not listed on the KEV catalog. Prioritize patching during standard maintenance windows for security research and analysis infrastructure. Organizations with less frequent Rizin usage can defer updates slightly longer than those running continuous malware or vulnerability analysis operations.

Risk score, explained

The CVSS 3.1 score of 3.3 reflects multiple mitigating factors. Attack Vector (Physical) and the requirement for user interaction (UI:R) significantly limit the threat model. Privilege requirements (PR:L) and high attack complexity (AC:H) further constrain the likelihood of successful exploitation. The impact is limited to integrity and availability (C:N/I:L/A:L), with no confidentiality breach. The scope change (S:C) acknowledges potential cross-component effects, but the low overall severity appropriately captures that this is a stability concern rather than a critical security defect.

Frequently asked questions