Eclipse ThreadX GUIX EUVD-2026-105040

Requires the target embedded application to load an attacker-controlled or tampered GUIX binary font resource through the binary resource loader; the malicious page header must declare first_glyph > last_glyph to trigger the unsigned underflow. Exploitation is limited by: Local attack vector (AV:L) - the crafted resource must reach the device (update channel, removable media, or externally supplied asset); required active user/application interaction (UI:A) to load the resource; and High attack complexity (AC:H) in turning the heap overflow into reliable control. The dominant real-world limiter is that many embedded deployments ship trusted, build-time font resources and never parse untrusted ones - only devices/applications that load externally sourced GUIX resources are realistically exposed.

This is a CWE-190 integer overflow leading to an undersized heap allocation and an out-of-bounds write in the Eclipse ThreadX GUIX binary resource (font) loader. The provided CVSS 4.0 vector (AV:L/AC:H/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H, score 7.1 High) tells the real story: although no privileges are required (PR:N), exploitation is NOT remote unauthenticated internet-facing - it is Local (AV:L) with required user/application interaction (UI:A) and High attack complexity (AC:H), because the attacker must craft a malicious binary resource that reliably wins the overflow and is then loaded by the target application. No EPSS score, SSVC decision, KEV listing, or public POC was supplied in the input, so there are no signals of active exploitation or weaponization - exploitation status is therefore 'no public exploit identified at time of analysis.' Net: this is a legitimately serious memory-corruption bug (full VC/VI/VA High, consistent with heap corruption that can escalate to code execution on constrained embedded targets) but a moderate operational priority rather than a drop-everything emergency, because it depends on the device/application consuming attacker-supplied font resources rather than trusted build-time assets. One data conflict to flag: the 'Information Disclosure' tag is inconsistent with the described mechanism, which is an out-of-bounds WRITE of attacker-controlled glyph records (memory corruption), not primarily a read/disclosure primitive - treat the tag with skepticism.

An attacker crafts a malicious GUIX binary font resource whose page header sets first_glyph greater than last_glyph; when the embedded application loads this resource, the glyph count underflows and the unchecked size multiply wraps, so the loader allocates a tiny buffer and then writes attacker-controlled glyph records past its end, corrupting the heap. Because the CVSS vector is AV:L with UI:A, this requires the resource to reach the device and the application to actively load it (e.g., via an update, removable media, or an app-supplied asset), not a remote network request. No public exploit code was identified at time of analysis.