EUVD-2026-110474
GHSA-8632-wqc3-gg8p
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessCraft undersized GBR file (0x21-0x162 bytes)
-
ExploitDeliver to victim via file sharing
-
Executiongbr_open scans title field past buffer
-
ImpactCrash gbsplay or leak adjacent heap memory
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Bounds checking, read limits
MITRE ATT&CK
1 technique across 1 tactic: Collection The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires a victim to load/play an attacker-supplied crafted GBR file of exactly 0x21 to 0x162 bytes in gbsplay version ≤0.0.103; the default configuration is vulnerable (no special feature or setting must be enabled). The limiting factors are: the attack vector is local (the malicious file must reach and be opened by the user, matching UI:P/UI:R), there is no authentication involved, and the impact is confined to crashing the player or disclosing a small amount of adjacent heap memory via the title field - there is no code execution or integrity impact. |
| Impact | This is a genuinely low-priority issue despite a medium CVSS 4.0 base score of 4.8. The signals are consistent rather than conflicting: the CVSS vector is local (AV:L) with passive user interaction (UI:P) and no privileges (PR:N), EPSS is 0.13% (2nd percentile - near the bottom), SSVC reports Exploitation=none, Automatable=no, Technical Impact=partial, and the vuln.today decision label is 'this_month' (not act_now/emergency). The flaw is not in CISA KEV. Impact is bounded - the CVSS vector marks only availability (VA:L), i.e. a crash, with no integrity or code-execution impact. One discrepancy to verify: the input CVSS sets VC:N (no confidentiality impact), yet the description and the 'Information Disclosure' tag both state the bug can 'leak memory' by reading past the heap buffer while scanning the displayed title field - so a minor heap information leak is plausible and the official vector may understate confidentiality. Either way this is a crash/limited-disclosure bug in a niche tool, not a high-real-risk priority. |
| Exploit ScenarioDerived | An attacker crafts an undersized GBR file (0x21-0x162 bytes) and shares it on a chiptune/ROM distribution site; a victim opens it in gbsplay ≤0.0.103. gbr_open() in gbs.c scans the ROM title field from offset 0x154 to 0x162 without checking the file length, reading past the heap buffer and either crashing gbsplay or exposing adjacent heap memory. A public PoC reference exists (a hackmd write-up and a VulnCheck advisory); it is not verified as working exploit code. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 28, 2026
Heap out-of-bounds read in gbsplay 0.0.103 and earlier lets anyone who opens a crafted GBR file sized between 0x21 and 0x162 bytes read past the end of a heap buffer while gbr_open() in gbs.c scans the ROM title field, crashing the player or leaking a small amount of adjacent heap memory. The flaw is reachable in the default configuration with no special option enabled, but it requires the victim to load the attacker-supplied file locally, so it is a low-priority local issue with no code execution or integrity impact (CVSS 4.0 base 4.8; independent assessment CVSS 3.1 AV:L/AC:L/PR:N/UI:R, C:L/A:L; EPSS 0.13%, 2nd percentile). Vulnerability is not in CISA KEV and SSVC records exploitation as none; a public technical writeup describing the flaw exists, and an upstream fix commit is available.
RemediationAI
Apply the upstream vendor fix commit 33812ed38d84b800b5a17f639ef6625f76290785 (https://github.com/mmitch/gbsplay/commit/33812ed38d84b800b5a17f639ef6625f76290785), which adds the missing i<size bound to the title-field loop in gbr_open(); patch availability is confirmed by the vendor, but a tagged release version containing the fix is not stated in the available data, so confirm whether your distribution's package build already carries this commit before relying on a version number. Until a fixed build is deployed, the practical compensating control is to avoid opening untrusted .gbr files, or to pre-validate file length and reject GBR inputs shorter than 0x163 bytes, since only files of 0x21 to 0x162 bytes reach the out-of-bounds read; the trade-off is that legitimately truncated or small ROM images will also be refused. Track the issue at https://github.com/mmitch/gbsplay/issues/201 and monitor the VulnCheck advisory (https://www.vulncheck.com/advisories/gbsplay-through-0.0.103-heap-out-of-bounds-read-via-gbr-open-gbr-title) for a corrected release; given EPSS 0.13%, no KEV listing and SSVC exploitation of none, this sits in the vendor's this-month remediation window rather than an emergency response.
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
gbsplay is a C-based Game Boy sound player that also opens GBR ROM images, and gbr_open() in gbs.c parses the file header from a heap buffer whose length is passed in as the size argument. The vulnerable code walks the GBR ROM title field with a fixed-offset loop, for (i=0x0154; i<0x0163; i++), and never compares the index against size, so a file that ends before offset 0x0163 causes the loop to read bytes beyond the allocation. This is a classic CWE-125 out-of-bounds read: no write occurs, but the over-read can walk off the heap buffer, producing a crash or disclosing a handful of adjacent heap bytes through the parsed title field. The supplied commit diff (33812ed38d84b800b5a17f639ef6625f76290785) fixes exactly this by adding the missing bound, for (i=0x0154; i<0x0163 && i<size; i++). The CPE string cpe:2.3:a:mmitch:gbsplay:*:*:*:*:*:*:*:* confirms the affected package is the upstream mmitch gbsplay codebase, and the source reference points at gbs.c lines 810-820 in the 0.0.103 tag. The trigger is fully described by the sources; no additional memory-safety mechanism is documented.
Know when Gbsplay gets its next vulnerability
- 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:L/SC:N/SI:N/SA:N
Local parsing of an attacker-supplied file the victim must open (AV:L, UI:R), no privileges; out-of-bounds title bytes may be displayed (C:L) and the parser can crash (A:L), no integrity impact.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
DescriptionCVE.org
Gbsplay through 0.0.103 contains a heap out-of-bounds read vulnerability in gbr_open() in gbs.c that fails to verify file length before scanning the GBR ROM title field. Attackers can supply a crafted GBR file of 0x21 to 0x162 bytes to read past the heap buffer, crashing gbsplay or leaking memory.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
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
A buffer overflow occurs when a program writes more data to a memory buffer than it was allocated to hold, causing the excess data to spill into adjacent memory regions.
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
An out-of-bounds read in gbsplay 0.0.103 and earlier lets a crafted Game Boy sound file crash the player: mapper_map() i
Heap out-of-bounds read in gbsplay's VGM loader (vgm_open() in gbs.c) allows a crafted .vgm file to walk the command-str
Exploit-DB