Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessDistribute crafted GZF packed database file
-
DeliveryVictim or pipeline imports the file
-
ExploitBinaryField.read() passes unchecked 32-bit length to DataBuffer.get()
-
ExecutionHuge byte[] allocation triggers Java heap OutOfMemoryError
-
ImpactImport aborts and Ghidra JVM session/pipeline crashes
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Memory allocation limits
|
| Exploitation Conditions | Exploitation requires a user (or an automated headless Ghidra instance) to import a crafted GZF packed database file through the GzfLoader import path; the malicious file must contain a DB BinaryField record whose 32-bit length field is set to an arbitrarily large value. Triggering factors that LIMIT exploitation: passive user interaction is required (UI:P) - the victim must be persuaded to import the attacker-supplied file, and the vector is local (AV:L), so there is no remote unauthenticated network exposure. No authentication or privileges are needed (PR:N). Impact is confined to availability (process crash and loss of unsaved work); the condition that most amplifies real risk is deployment in automated binary-analysis/triage pipelines using headless Ghidra, where a single malicious sample crashes the processing queue. All versions through 12.2 are affected; the fix is upgrading to 12.2. |
| Impact | This is a medium-severity, availability-only denial-of-service issue, not a high-impact priority. The vendor CVSS 4.0 vector (CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H) scores 6.8 and confirms the shape: local attack vector, low complexity, no privileges (PR:N), but passive user interaction required (UI:P), and impact limited strictly to availability (VC:N/VI:N/VA:H) - there is no confidentiality or integrity loss. Exploitation status is 'no public exploit identified at time of analysis' (no CISA KEV listing and no input field confirming public exploit code), though the GHSA advisory publishes the exact triggering mechanism, source lines, and a full OutOfMemoryError stack trace, which materially lowers the barrier to reproducing it. The vuln.today decision label is 'this_month' rather than act_now/emergency, consistent with a DoS that requires user action. EPSS is not provided in the input, so exploitation probability cannot be quantified here. Note a data conflict: the input Tags label this 'Information Disclosure', but every signal (CWE-789 uncontrolled allocation, VC:N/VI:N, VA:H, description, and advisory) establishes it as availability-only denial of service - the tag is wrong. Realistic risk is elevated specifically for automated/headless Ghidra triage pipelines where a single malicious sample can crash the processing queue; for interactive analysts the consequence is a crashed session and loss of unsaved work. |
| Exploit ScenarioDerived | An adversary distributing malware embeds a crafted GZF packed database file whose BinaryField record encodes an arbitrarily large 32-bit length value. An analyst (or an automated headless pipeline) imports the file; PackedDatabase.open() parses the record and DataBuffer.get() attempts to allocate a byte array of the attacker-chosen size, immediately triggering a Java heap OutOfMemoryError that aborts the import and crashes the Ghidra JVM. No public exploit code is identified at time of analysis, but the GHSA advisory publishes the full trigger mechanism and stack trace. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 22, 2026
Heap exhaustion in Ghidra's GZF packed-database import path can crash the JVM when a user or automated headless pipeline opens a crafted DB file whose BinaryField length is set to an arbitrarily large value. The issue is local and requires the victim to import the file; impact is availability-only (OutOfMemoryError, aborted import, and loss of unsaved work), and the supplied data records no public exploit at time of analysis. Version scope is conflicting across sources: the GHSA lists vulnerable versions below 12.2 with the fix in 12.2, while the NVD description and independent assessment refer to Ghidra through 12.2.
RemediationAI
Upgrade to Ghidra 12.2, which the GHSA package metadata lists as the fixed version and which the independent assessment identifies as the remediation target; because the NVD wording refers to Ghidra through 12.2, verify the exact installed build against the vendor advisory at https://github.com/NationalSecurityAgency/ghidra/security/advisories/GHSA-q538-hhhf-5jxp. The GHSA fix guidance calls for max-length checks in DataBuffer.get() and BinaryField.read(), plus reading and sanitizing the length through readLength() in DBRecord.read(). No vendor workaround is described; an exposure reduction consistent with the described import path is to avoid opening untrusted GZF packed databases and to run headless imports in disposable, isolated workers so an OutOfMemoryError does not stall the main processing queue.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Ghidra's database framework reads record fields through DBRecord.read(), BinaryField.read(), and DataBuffer.get(). BinaryField.read() takes a 32-bit length from the serialized DB stream and passes the positive value directly to DataBuffer.get(), which allocates a new byte array of that size before any max-length validation; negative lengths are handled separately by setting the field data to null. The GHSA assigns CWE-789 (uncontrolled memory allocation) and also CWE-20, and the supplied stack trace confirms the path GzfLoader.loadPackedProgramDatabase() -> PackedDatabase.open() -> DBHandle -> MasterTable -> DBRecord.read() -> BinaryField.read() -> DataBuffer.get(), ending in java.lang.OutOfMemoryError. The trigger is a crafted GZF packed database imported into Ghidra, including headless automated analysis pipelines. No CPE strings were supplied; the provided tag 'Information Disclosure' is inconsistent with the availability-only denial-of-service impact described by the advisory and assessed vector.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Local processing of an attacker-supplied file requiring the user to initiate import (AV:L, UI:R), no privileges (PR:N), and heap-exhaustion crash yields availability-only impact (C:N/I:N/A:H).
Primary rating from Vendor (vulncheck).
CVSS VectorVendor: vulncheck
DescriptionCVE.org
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.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
EUVD-2026-108329
GHSA-cj2j-2w64-7q9c
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB