Live › vulnerability › CVE-2026-115394
Go to dashboardGhidra through 12.2 trusts a 32-bit length field in BinaryField.read(), so a crafted packed database file can make it allocate huge amounts of heap memory. Opening that file in Ghidra crashes the import with an OutOfMemoryError, which is a denial of service rather than code execution.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Teams that use Ghidra for reverse engineering and import shared GZF packed databases from outside their own organisation are the ones exposed. Users who only analyse their own binaries and never open files from third parties have little reason to worry. The sources do not describe a server-side or networked exposure.
No product ranges from the sources yet.
ghidra --version or check the version shown in Help > About to see whether it is 12.2 or earlier12.2Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-115394")
NVD data is provided by NIST and is public domain · EPSS scores by FIRST, used with attribution. Posts quoted belong to their authors.