Ghidra CVE-2026-115398

Exploitation requires that a user of Ghidra before 12.2 open or batch-import an attacker-supplied TAR or ZIP archive, which triggers the TarFileSystem/ZipFileSystem mount path and the FileSystemIndexHelper indexing routine that stores archive entries with no entry-count limit. The specific trigger is an archive crafted with an excessively large number of entries (not necessarily large file size), causing unbounded per-entry allocation that exhausts the Java heap. Limiting factors that reduce real-world risk: the attack is local and file-delivery based (AV:L), it requires the victim to actively open/import the file (UI:P - no drive-by or remote network trigger), it affects availability only (no data disclosure or code execution), and it is fully remediated by upgrading to 12.2, which enforces a 500,000-entry cap.

This is a genuine but modest-priority issue, not a high-urgency emergency. The supplied CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H) scores 6.8 and is internally consistent with the description: impact is availability-only (VA:H, with VC:N and VI:N), the attack is local (AV:L) because it requires feeding a file to the Ghidra process, and it requires passive user interaction (UI:P) - the victim must open or batch-import the crafted archive. There is no confidentiality or integrity impact and no code execution; the worst outcome is a hung session and system-wide memory pressure requiring a forced process kill. KEV status is NO (not listed by CISA), so this is not confirmed actively exploited. No EPSS score was provided in the input, so exploitation probability cannot be quantified from the data. The vuln.today decision label is 'this_month' (not act_now/emergency), aligning with a fix-on-normal-patch-cycle posture. No SSVC decision record was supplied. The one mild tension worth flagging: PR:N labels the flaw unauthenticated, yet UI:P and AV:L mean an attacker cannot act without first delivering a file and relying on the victim to open it, so real-world exploitation is gated by social engineering rather than direct remote reach. Overall this is a low-cost/high-impact-asymmetry DoS (a small file can exhaust memory) but confined to a desktop reverse-engineering tool and dependent on user action.

An attacker crafts a small TAR or ZIP archive containing an excessive number of entries (entry count, not file size, drives the impact) and persuades a reverse-engineering analyst to open or batch-import it in Ghidra before 12.2. During the unbounded indexing loop in FileSystemIndexHelper, the Java heap is exhausted, the UI thread blocks, and the session hangs - requiring a forced kill (Task Manager / kill -9) and potentially degrading other applications on the host. No working public exploit code is identified at time of analysis, though the GHSA advisory and VulnCheck advisory publicly document the vulnerable code path and a reproducing stack trace.