Ghidra CVE-2026-113604

Exploitation requires a victim to load an attacker-supplied ELF file into Ghidra - either through the GUI import/load-spec discovery step or via a headless analysis pipeline that automatically ingests untrusted binaries. The malicious file need only be 128 bytes and the flaw triggers against default configurations during normal ELF parsing (no special feature toggle is required). The limiting factors are: the local attack vector (the file must reach the analyst's system) and the required user/pipeline interaction of actually importing the file; there is no authentication prerequisite on the target, but the attacker cannot trigger it remotely without that load action. Impact is confined to availability (process/job crash via OutOfMemoryError) with no code execution, data disclosure, or integrity effect.

This is a moderate-severity denial-of-service issue, not a critical priority. The CVSS 4.0 base score of 6.8 is driven almost entirely by a high availability impact (VA:H) with no confidentiality or integrity consequences (VC:N/VI:N), and the vector is local with required passive user interaction (AV:L/UI:P) - meaning an analyst must actually load a crafted file. There is no CISA KEV listing and no public exploit was provided in the intelligence, so exploitation status is 'no public exploit identified at time of analysis.' No EPSS score was supplied, so widespread-exploitation probability cannot be quantified from the data. The signals are internally consistent: the root cause (CWE-789, allocation sized by unvalidated ELF extended header counts) matches a VA:H/no-C/no-I DoS, and the local attack vector matches a tool that imports files an analyst chooses to open. The practical worst case is a crash of a single Ghidra process or a headless analysis job (OutOfMemoryError), not host compromise or lateral movement. Real-world risk is bounded: the main concern is disruption of automated malware-triage/headless pipelines that ingest untrusted samples, where an attacker-controlled sample could reliably crash analysis.

An attacker distributes a malicious 128-byte ELF file (e.g., as a malware sample sent to or collected by a reverse-engineering team). When an analyst imports it into Ghidra - or an automated headless pipeline ingests it for load-spec discovery - the ELF loader allocates arrays sized by the file's unvalidated extended program/section header counts, exhausting the JVM heap and raising an OutOfMemoryError. No public exploit was identified at time of analysis, but the vendor-patched commit makes the vulnerable code path and trigger conditions clear.