CVE-2026-110735 in Godot Engine
Summary
by MITRE • 10/14/2026
Godot Engine through 4.7.2 has a heap out-of-bounds write exists in the binary resource loader (core/io/resource_format_binary.cpp, ResourceLoaderBinary::get_unicode_string). A string length is read from the resource file into a signed 32-bit integer and compared against the destination buffer size with a signed comparison, which conditionally resizes the buffer. A negative length value skips the resize; the same value is then passed to the copy routine as an unsigned byte count, where it sign-extends to a huge value, copying file-controlled data far past the undersized heap allocation. The defect is reached when the product or an exported game loads a crafted binary resource file (.res). NOTE: the Supplier's position is that the research has identified "no security issues" because the required attacker access is outside of the current Godot Engine threat model.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/14/2026
The vulnerability in question resides within the binary resource loader component of the Godot game engine, specifically affecting versions up to 4.7.2. The core technical flaw is a heap-based out-of-bounds write that occurs during the parsing of Unicode strings from serialized resource files. This issue stems from an improper handling of integer data types and a lack of rigorous bounds checking when processing input derived from external sources. When the engine loads a binary resource file, it reads a string length value into a signed 32-bit integer variable. The subsequent logic compares this value against the size of the destination buffer using a signed comparison to determine if the buffer needs resizing. This approach introduces a critical logical error because negative values are treated as valid lengths that do not trigger a resize operation, despite being invalid for memory allocation purposes.
The exploitation mechanism relies on the discrepancy between how the length is interpreted during the conditional check and how it is used in the actual data copy routine. If an attacker crafts a binary resource file containing a string with a negative length value encoded as a signed integer, the condition to resize the buffer fails because the negative number is not greater than the current buffer size under signed comparison rules. Consequently, the engine proceeds to use this same negative value for copying data into the allocated heap memory. However, when passed to the copy routine, which expects an unsigned byte count, the negative signed integer undergoes sign extension. This process converts the small negative number into a very large positive unsigned integer, causing the system to attempt writing file-controlled data far beyond the boundaries of the undersized heap allocation.
This type of memory corruption is classified under CWE-787: Out-of-bounds Write and CWE-190: Integer Overflow or Wraparound. The vulnerability allows for arbitrary code execution potential if an attacker can control the content written past the buffer boundary, potentially overwriting adjacent heap metadata or function pointers. In the context of game development tools and distributed games, this could lead to remote code execution when a victim loads a maliciously crafted project file or asset package. From a threat modeling perspective, such vulnerabilities are often associated with CWE-20: Improper Input Validation, as the system fails to adequately validate that input data conforms to expected constraints before processing it in memory operations.
The operational impact of this vulnerability is significant for developers and end-users who rely on Godot Engine projects involving custom or third-party assets. An attacker could distribute a malicious .res file disguised as legitimate game content. Upon loading, the engine would execute the flawed code path, leading to heap corruption that may crash the application or be leveraged for further exploitation steps such as shellcode injection. Although the vendor has stated that they do not consider this a security issue due to their threat model which assumes trusted input in certain contexts, this stance overlooks scenarios where assets are sourced from untrusted parties, modding communities, or online marketplaces where integrity cannot be guaranteed.
Mitigation strategies should focus on both immediate patching and long-term defensive coding practices. The primary remediation is to upgrade the Godot Engine installation to version 4.7.3 or later, where this integer handling logic has been corrected to properly validate string lengths as positive values before allocation and copy operations. For environments unable to update immediately, developers should implement strict input validation on all external resource files prior to loading them into the engine. This includes verifying that length fields are within expected bounds and are non-negative. Additionally, enabling Address Sanitizer during development builds can help detect such memory errors early in the software lifecycle. From a defense-in-depth perspective, employing operating system-level protections like Heap Randomization (ASLR) and Data Execution Prevention (DEP) can reduce the likelihood of successful exploitation by making it harder for attackers to predict memory layouts or execute injected code.
In terms of attack classification within frameworks such as MITRE ATT&CK, this vulnerability aligns with techniques related to initial access via malicious files and subsequent execution through memory corruption exploits. Specifically, it relates to T1203: Exploitation for Client Execution if the vector involves tricking a user into opening a file. The root cause is fundamentally an input validation failure that leads to improper resource management, highlighting the importance of treating all external data as untrusted regardless of its source within the application's operational context. Ensuring robust type safety and explicit casting checks in low-level memory operations is essential for maintaining the integrity of game engines used by a wide community of creators who may not have deep security expertise.