LOW 3.3

CVE-2026-45613: Rizin Heap Buffer Over-Read in OMF File Parser

Rizin, a reverse engineering framework used by security researchers and analysts, contains a heap buffer overflow vulnerability in its OMF (Object Module Format) file parsing code. An attacker could craft a malicious OMF binary file that, when opened by a user in Rizin, could read small amounts of sensitive data from the program's memory. This requires local access and user interaction—the user must deliberately open a malicious file.

Source data · NVD / CISA · public domain

CVSS
3.1 · 3.3 LOW · CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N
Weaknesses (CWE)
CWE-125
Affected products
0 configuration(s)
Published / Modified
2026-05-29 / 2026-06-17

NVD description (verbatim)

Rizin is a UNIX-like reverse engineering framework and command-line toolset. There is a heap-buffer-overflow in librz/bin/format/omf/omf.c. This vulnerability is fixed by commit e6d0937c8a083e23ed76ccfb9f631cdc50c7af47.

2 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-45613 is a heap-based buffer over-read (CWE-125) located in librz/bin/format/omf/omf.c within Rizin's binary format parsing subsystem. The vulnerability allows an out-of-bounds read when processing specially crafted OMF files. The flaw permits disclosure of adjacent heap memory contents without corruption or denial of service. Remediation is available via commit e6d0937c8a083e23ed76ccfb9f631cdc50c7af47, which corrects the boundary check logic in the OMF parser.

Business impact

For security teams and reverse engineering operations, this vulnerability presents a low operational risk. Exploitation requires a user to manually open a malicious binary file—it does not propagate through network access or affect systems running Rizin passively. The primary concern is information disclosure: an attacker could learn whether specific data patterns exist in memory, potentially revealing details about other processes or cached credentials. Organizations relying on Rizin for trusted binary analysis should plan updates within standard maintenance windows rather than treating this as an emergency.

Affected systems

Any installation of Rizin prior to the commit containing the fix (e6d0937c8a083e23ed76ccfb9f631cdc50c7af47) is potentially vulnerable. The vulnerability affects all major platforms where Rizin runs (Linux, macOS, Windows) and impacts both interactive users and automated analysis pipelines that process untrusted binary files. No specific version boundaries are published; verify your Rizin version against the vendor's official release notes.

Exploitability

Exploitation requires low technical skill but high user interaction. An attacker must craft a malicious OMF file and convince or trick a user into opening it within Rizin. No network vector exists. The vulnerability cannot be exploited remotely and does not escalate privileges or enable code execution. The CVSS score of 3.3 (LOW) reflects these constraints: local access, user interaction required, and confidentiality impact only.

Remediation

Update Rizin to a version incorporating commit e6d0937c8a083e23ed76ccfb9f631cdc50c7af47 or later. Consult your Rizin distribution's release notes to identify the specific version that includes this fix. Additionally, implement controls to restrict opening untrusted binary files in Rizin, particularly in environments where analysts process files from unknown or adversarial sources.

Patch guidance

Verify the commit hash e6d0937c8a083e23ed76ccfb9f631cdc50c7af47 in your Rizin repository or release notes to confirm the fix is included. If using a packaged version (e.g., from a Linux distribution or Homebrew), check for updates to Rizin and apply them. If running a development build, rebuild from the latest main branch or the stable branch containing this commit. Document the patched version in your asset inventory.

Detection guidance

Monitor system logs for unusual Rizin process behavior or crashes when processing OMF files. Implement file-type validation to warn users before opening OMF files from untrusted sources. Network-based detection is not applicable. Endpoint detection and response (EDR) tools can flag heap overflow-related process anomalies if available; however, this vulnerability may not consistently trigger observable signals. Proactive detection depends primarily on patch compliance audits.

Why prioritize this

This vulnerability merits standard-priority patching rather than emergency response. The lack of network exploitability, requirement for user interaction, and limited impact scope (information disclosure only) place it in the maintenance-cycle category. However, organizations running automated binary analysis on third-party files should treat it with slightly higher urgency to minimize the window for potential data leakage. Prioritize patching in lab and analysis environments ahead of isolated research systems.

Risk score, explained

The CVSS 3.1 score of 3.3 reflects a LOW-severity vulnerability. The score is driven by several mitigating factors: attack vector is local (AV:L), attack complexity is low (AC:L), no privileges are required (PR:N), user interaction is mandatory (UI:R), and the impact scope is unchanged (S:U). Confidentiality impact is rated low (C:L), with no integrity or availability impact (I:N, A:N). This profile is consistent with a file-parsing flaw that leaks heap memory contents only when a user deliberately interacts with a malicious file.

Frequently asked questions

Can this vulnerability be exploited over the network?

No. The vulnerability requires local file access and user interaction. An attacker cannot exploit it remotely; they must either have local system access or convince a user to open a malicious OMF file.

Will this vulnerability crash Rizin or corrupt my analysis?

No. The vulnerability is a heap over-read that leaks memory contents, not a write operation. It does not cause denial of service, data corruption, or system instability under normal conditions.

How urgent is patching for my security team?

Patch within your standard maintenance cycle, typically 2–4 weeks. If your team processes untrusted or adversarial binaries regularly, prioritize sooner to minimize information disclosure risk. This is not a zero-day or active exploitation scenario.

What should I do if I've opened a suspicious OMF file before patching?

The vulnerability reads adjacent heap memory, which is typically non-persistent and lost when Rizin terminates. There is no persistent data compromise. After patching, no further action is required unless you have reason to believe sensitive data (like API keys) was in Rizin's memory during the session.

This analysis is provided for informational purposes and represents SEC.co's interpretation of publicly available vulnerability data as of June 2026. Specific version numbers, patch timelines, and vendor details should be verified directly against official Rizin release notes and vendor advisories. No guarantee is made regarding the completeness or real-time accuracy of this assessment. Organizations should conduct their own risk assessment and testing before deploying patches in production environments. SEC.co is not liable for decisions made based on this intelligence. Source: NVD (public-domain), retrieved 2026-07-07. Analysis generated by SEC.co (claude-haiku-4-5).