CVE-2026-116726 in Gbsplay
Summary
by MITRE • 10/27/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/27/2026
The vulnerability identified in gbsplay versions up through 0.0.103 represents a critical security flaw rooted in improper input validation within the application's file parsing logic. Specifically, the defect resides in the gbr_open function located in the source file gbs.c, which is responsible for handling Game Boy ROM files with GBR extensions. The core technical issue is a heap-based out-of-bounds read that occurs when the software attempts to scan and parse the title field of the provided ROM image. During this process, the application fails to perform adequate bounds checking against the actual file size before accessing memory locations beyond the allocated buffer boundaries. This lack of verification allows an attacker who can supply a specially crafted GBR file with a length between 0x21 and 0x162 bytes to trigger the erroneous read operation. By carefully constructing such a malicious input, it is possible to force the application to access memory regions that are not part of the intended heap allocation for the ROM data structure.
From a technical perspective, this vulnerability aligns with Common Weakness Enumeration (CWE) category CWE-125, which describes out-of-bounds read errors resulting from insufficient validation of array or buffer indices and lengths. The absence of strict length verification prior to memory access operations is a classic example of this weakness class. When the gbr_open function processes the crafted file, it proceeds to read data beyond the end of the heap-allocated buffer without confirming that sufficient bytes are available within the file's actual size constraints. This behavior violates fundamental principles of secure coding where all external inputs must be validated against expected limits before being processed or used for memory access operations. The specific range of affected file sizes indicates a narrow but exploitable window where the malformed input can bypass internal checks while still triggering the out-of-bounds condition during title field extraction.
The operational impact of this vulnerability is significant, primarily manifesting as either denial of service or potential information disclosure depending on the memory layout at runtime. In most scenarios, attempting to read from unmapped or protected heap regions will result in a segmentation fault, causing gbsplay to crash abruptly and terminate unexpectedly. This constitutes a reliable denial-of-service vector against users who open maliciously crafted GBR files through the application interface. However, under certain conditions where the out-of-bounds memory access lands within mapped but unintended portions of the process heap, there is a risk of sensitive data leakage. An attacker could potentially exfiltrate contents from adjacent heap allocations, which may include pointers to other objects, stack canaries, or even parts of previously allocated buffers containing user data. This transforms what might initially appear as a simple crash into a potential vector for memory disclosure attacks that aid in further exploitation stages such as return-oriented programming bypasses.
Mitigation strategies should focus on immediate patching and defensive coding practices to address this flaw. The primary remediation involves updating gbsplay to version 0.0.104 or later, where the developers have presumably implemented proper bounds checking within the gbr_open function. For environments unable to upgrade immediately, implementing input validation at the application entry point is advisable by rejecting any GBR files that do not meet minimum size requirements for valid title fields before passing them deeper into the parsing logic. Developers should also adopt static analysis tools and fuzzing techniques during future development cycles to detect similar out-of-bounds conditions early in the software lifecycle. Additionally, enabling compiler security features such as stack canaries and address space layout randomization can help mitigate exploitation attempts by making memory disclosure more difficult and crashes less predictable for attackers leveraging this vulnerability.