Godot Engine EUVD-2026-101305

Requires the victim to load a specifically crafted Godot binary resource (.res) file - either opened in the Godot editor or loaded at runtime by an exported game that ingests external or user-supplied resource files (mods, downloaded assets, user-generated content). The crafted file must encode a negative value in the signed 32-bit Unicode-string length field so the signed size comparison skips the buffer resize and the value sign-extends into a large unsigned copy count. LIMITING FACTORS: (1) the attacker must get a malicious .res file to reach and be loaded by the victim (local vector, user interaction), raising delivery difficulty; (2) reliable code execution requires heap-grooming (high attack complexity); (3) the vendor considers loading untrusted .res files outside Godot's threat model, so default/intended usage treats resource files as trusted - the condition is primarily relevant to deployments that process third-party or untrusted resource files.

This is a low-urgency, technically-interesting issue rather than an operational emergency. The input CVSS 3.1 vector (AV:L/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N, base 2.5) models the flaw as a local, high-complexity, user-interaction-dependent bug with only low integrity impact - which materially UNDERSTATES the technical primitive. CWE-195 combined with the description (signed 32-bit length, skipped resize, sign-extension to an unsigned byte count, file-controlled copy past an undersized heap allocation) is a classic heap out-of-bounds write that in principle enables memory corruption up to arbitrary code execution, so the I:L/C:N/A:N impact rating is conservative and arguably wrong - see assessed_cvss_vector where I rate impact higher. On the real-world-risk side, however, the mitigating signals dominate: no EPSS score was provided, there is NO CISA KEV listing, and NO public exploit was identified in the input (a referenced research write-up discusses the memory-safety bugs but is not confirmed weaponized exploit code). No SSVC decision data was supplied. Critically, the Supplier (Godot) explicitly disputes this as a security issue, arguing that loading an untrusted/crafted .res file is OUTSIDE the current Godot Engine threat model - i.e., resource files are assumed trusted, analogous to loading native code. CONFLICT TO FLAG: the raw CWE/heap-write severity conflicts with both the low CVSS and the vendor's not-a-vuln position; prioritization should hinge on whether your deployment ever loads untrusted .res files (e.g., user-generated content, mods, downloaded game assets). For default single-trust-domain game distribution, real risk is low; for engines/games that ingest third-party resource files, treat it as a genuine memory-corruption exposure.

An attacker crafts a malicious Godot binary resource (.res) file encoding a negative 32-bit Unicode-string length, then delivers it to a victim who loads it in the Godot editor or via an exported game that ingests external/user-supplied resource files (e.g., mods or downloaded assets). When ResourceLoaderBinary::get_unicode_string processes it, the negative length skips the buffer resize and sign-extends to a huge unsigned copy size, writing file-controlled data far past the undersized heap allocation. Exploitation requires user interaction to open the file and high complexity (heap layout control for reliable code execution); no public weaponized exploit was identified in the provided data.