CVE-2026-115394 in Ghidra
Summary
by MITRE • 10/22/2026
Ghidra through 12.2 contains an uncontrolled memory allocation vulnerability in BinaryField.read() that allows attackers to exhaust heap memory via an unchecked 32-bit length field. Attackers can persuade users to import a crafted GZF packed database file, triggering an OutOfMemoryError in PackedDatabase.open() that aborts the import and denies service.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified within Ghidra versions up through 12.2 represents a critical uncontrolled memory allocation flaw located specifically within the BinaryField.read method of its binary parsing infrastructure. This security defect stems from a fundamental lack of input validation regarding length fields extracted during the deserialization or reading process of binary data structures. When the software processes external inputs, particularly those involving complex database formats like GZF packed databases, it relies on metadata provided by the file itself to determine how much memory to allocate for storing the parsed content. In this specific instance, a 32-bit length field is read from the input stream without any subsequent bounds checking or sanity verification against system constraints or expected maximum sizes. This architectural oversight allows an attacker to craft a maliciously constructed GZF packed database file that contains an artificially inflated length value significantly exceeding available heap memory limits.
The operational impact of this vulnerability centers on resource exhaustion leading to denial of service conditions for the application and potentially the host system if not properly contained by operating-level safeguards. When a user is persuaded, through social engineering or deceptive means, to import such a crafted file into Ghidra, the software attempts to allocate memory based on the unchecked 32-bit length value. This action triggers an OutOfMemoryError within the PackedDatabase.open method as the Java Virtual Machine fails to satisfy the excessive allocation request. The immediate consequence is that the import operation aborts abruptly, disrupting the user's workflow and preventing access to the intended analysis data. While primarily a denial of service vector against the application itself, such memory exhaustion can also lead to instability in the host environment if garbage collection mechanisms are overwhelmed or if other processes sharing system resources are starved of necessary memory allocations during the spike caused by the failed allocation attempt.
From a classification perspective, this vulnerability aligns with CWE-789: Uncontrolled Memory Allocation, which describes situations where software allocates memory based on input without verifying that sufficient free memory exists to satisfy the request. Furthermore, in the context of adversary tactics and techniques, this flaw facilitates attacks categorized under MITRE ATT&CK technique T1496: Resource Hijacking, specifically within the sub-technique related to resource exhaustion. Attackers can leverage this weakness as a disruptive measure against security analysts or reverse engineers who rely on Ghidra for critical malware analysis tasks. The ability to crash the tool via a simple file import reduces the availability of essential forensic and reverse engineering capabilities, thereby hindering incident response efforts or threat intelligence gathering activities that depend on stable operation of such tools.
Mitigation strategies must address both immediate remediation and long-term defensive coding practices. For users currently affected by this vulnerability in Ghidra versions up to 12.2, the primary recommendation is to upgrade to a patched version where developers have implemented proper validation checks for length fields before memory allocation occurs. Until an update is available or if upgrading is not immediately feasible, organizations should enforce strict policies regarding the import of binary database files from untrusted sources. Implementing sandboxed environments for running Ghidra can help contain potential OutOfMemoryErrors and prevent them from impacting other critical systems on the host machine. Additionally, security teams should consider deploying application-level monitoring to detect abnormal memory usage patterns that may indicate exploitation attempts. Developers integrating similar parsing logic in future versions must ensure that all external length fields are validated against predefined maximum thresholds and system resource limits before any allocation is attempted, thereby eliminating the root cause of uncontrolled memory consumption.