CVE-2026-113604 in Ghidra
Summary
by MITRE • 10/20/2026
Ghidra 10.2 through 12.1.4 contains a denial of service vulnerability in the ELF loader's ElfHeader class that allocates arrays sized by unvalidated extended section and program header counts. Attackers can supply a crafted 128-byte ELF file that triggers an OutOfMemoryError during load-spec discovery at import or in headless analysis pipelines.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/20/2026
The vulnerability identified in Ghidra versions 10.2 through 12.1.4 represents a critical resource management flaw within the Executable and Linkable Format loader, specifically located in the ElfHeader class. This component is responsible for parsing the header structures of ELF binaries to determine their architecture, entry points, and section layouts prior to analysis. The core technical deficiency lies in the failure to validate extended section count and program header count fields before they are used as array size parameters during memory allocation. In a properly secured implementation, these values must be rigorously checked against maximum allowable limits defined by the ELF specification or internal application constraints. However, Ghidra’s loader accepts arbitrary integer values from the binary file without sufficient bounds checking, leading to the direct instantiation of arrays sized according to potentially malicious inputs rather than realistic structural expectations.
This lack of input validation allows an attacker to craft a minimal yet deceptive 128-byte ELF file that contains exaggerated counts for sections or program headers. When Ghidra processes this crafted binary during import operations or within headless analysis pipelines, the loader attempts to allocate memory arrays corresponding to these inflated numbers. Since there is no upper limit enforcement on the array size derived from untrusted input, the Java Virtual Machine encounters an OutOfMemoryError when attempting to satisfy the excessive allocation request. This error occurs specifically during load-spec discovery, a phase where Ghidra determines how to interpret and display the binary’s contents to the user or automated tools. The result is a complete denial of service for the affected instance, as the application crashes or becomes unresponsive due to the fatal exception thrown by the memory subsystem.
From an operational perspective, this vulnerability poses significant risks in environments where Ghidra is used extensively with untrusted inputs, such as malware analysis labs, automated reverse engineering pipelines, or software supply chain security tools that ingest binaries from external sources. An attacker who can force a victim to load a malicious ELF file can disrupt ongoing analysis sessions, cause data loss if unsaved work exists in the session database, and potentially create availability gaps in continuous integration or threat intelligence workflows that rely on Ghidra’s headless capabilities. The impact is particularly severe because it requires no special privileges beyond the ability to trigger the loading process, making it a low-barrier attack vector for disrupting security operations centers or research environments dependent on this tooling.
The technical nature of this flaw aligns with CWE-789: Uncontrolled Memory Allocation, as the application allocates memory based on externally influenced data without verifying that the size is within acceptable bounds. Furthermore, it relates to CWE-20: Improper Input Validation, since the specific fields governing array dimensions are not sanitized or constrained before use. In terms of adversary tactics, this vulnerability supports ATT&CK technique T1496: Resource Hijacking, where an attacker consumes system resources to degrade performance or availability. It may also be categorized under T1529: System Shutdown or Reboot if the resulting crash forces a restart of critical analysis infrastructure, although in most cases it manifests as a simple application-level denial of service rather than full system compromise.
Mitigation strategies for this vulnerability primarily involve updating to patched versions of Ghidra where the ElfHeader class has been hardened with proper validation logic. Until an update is applied, organizations should implement strict input filtering at network or ingestion boundaries to prevent untrusted ELF files from reaching the analysis environment. Additionally, configuring Java Virtual Machine memory limits and implementing robust exception handling around loader operations can help contain the impact of such crashes, preventing them from cascading into broader system instability. Security teams should also audit their automated pipelines for similar patterns where binary metadata is processed without adequate bounds checking to prevent recurrence in other components or future versions.