CVE-2026-110736 in Godot Engine
Summary
by MITRE • 10/15/2026
Godot Engine through 4.7.2 has an out-of-bounds read in the optimized translation loader (core/string/optimized_translation.cpp, OptimizedTranslation::get_message). Offsets read from the hash table of a crafted .translation resource are used as indices into the bucket table without bounds validation; only a single sentinel value is rejected. A crafted file can point an index far past the allocated buffer. Depending on the values, the result is a crash, or a string lookup (tr()) returns raw bytes from elsewhere in the process heap as the translated string, disclosing process memory. The defect is reached when the product or an exported game loads and performs lookups in a crafted translation file. 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/15/2026
The vulnerability identified within the Godot Engine, specifically affecting versions through 4.7.2, represents a critical out-of-bounds read flaw located in the optimized translation loader component found at core/string/optimized_translation.cpp. This defect manifests during the execution of the OptimizedTranslation::get_message function, which is responsible for retrieving localized strings from compiled translation resources. The root cause lies in the improper validation of data structures derived from .translation files. When a crafted translation file is loaded, it contains hash table entries that include offsets intended to point into an internal bucket table where actual string data resides. However, the implementation fails to perform rigorous bounds checking on these offset values before using them as array indices. Instead of validating that the calculated index falls within the allocated memory buffer for the bucket table, the code only rejects a single specific sentinel value. This insufficient validation allows maliciously crafted files to specify offsets that point far beyond the boundaries of the allocated heap memory associated with the translation data structure.
From an operational perspective, this lack of bounds checking leads to two distinct and severe outcomes depending on the specific values provided in the exploit payload. In many scenarios, accessing invalid memory addresses triggers a segmentation fault or similar access violation, resulting in an immediate application crash. This constitutes a denial-of-service condition against users who load untrusted translation assets. More critically, if the out-of-bounds read lands within valid but unintended regions of the process heap, the vulnerability enables information disclosure. The function may return raw bytes from adjacent memory locations as part of the translated string output. Since this data is often passed to user-facing interfaces or logging mechanisms via functions like tr(), sensitive information residing in the application's memory space can be exfiltrated. This could include cryptographic keys, session tokens, private user data, or other proprietary logic embedded within the game or engine runtime environment.
This vulnerability aligns with CWE-125, which describes an out-of-bounds read condition where software reads past the end of a buffer. The attack vector is classified under ATT&CK technique T1083, specifically related to File and Directory Discovery, as it involves parsing structured files that may contain malicious payloads designed for exploitation during normal application operation. While the vendor maintains that this does not constitute a security issue because loading arbitrary translation files falls outside their defined threat model—assuming users only load assets from trusted sources—the technical reality remains that any mechanism allowing external input to influence memory access patterns without proper validation is inherently risky. In complex engines like Godot, where plugins and community-contributed content are common, the assumption of a closed trust boundary is often fragile in practice.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. The primary fix involves implementing strict bounds checking within the OptimizedTranslation::get_message function to ensure that all indices derived from hash table offsets are validated against the actual size of the bucket table before access occurs. Developers should also consider adopting safer memory handling practices, such as using standard library containers with built-in range checks or explicit validation routines for all external data inputs. For users unable to immediately update their engine versions, restricting the loading of translation files to only those from verified and trusted sources can reduce exposure risk. Furthermore, enabling Address Sanitizer (ASan) during development builds is recommended to detect such memory errors early in the software lifecycle. As the industry moves toward more robust security standards, integrating static analysis tools that specifically target out-of-bounds access patterns will help prevent similar defects in future releases of game engines and related middleware.