GNU Emacs Android EUVD-2026-55257

The attacker must deliver a crafted sfnt/OpenType/TrueType font file through one of the following channels: (1) an email opened and rendered inside GNU Emacs on Android, (2) a webpage loaded via EWW (Emacs Web Wowser) that references the malicious font, or (3) a document or configuration file with a custom font face pointing to the crafted font. The user must actively open or render the content containing the malicious font - passive delivery alone is insufficient. The most severe outcome (arbitrary memory access beyond information disclosure and crashes) is further constrained to 32-bit Android targets; on 64-bit devices the impact is limited to information disclosure and process crashes. No special server-side configuration or privileged account is required from the attacker's perspective.

The CVSS 4.0 score of 5.3 (Medium) reflects the mandatory user interaction (UI:P) and the constrained direct impact on the vulnerable system (VC:N/VI:N/VA:L), with limited subsequent-system confidentiality and integrity risk (SC:L/SI:L). The network attack vector (AV:N) and no privilege requirement (PR:N) increase accessibility, but the user-interaction requirement is a real friction point - exploitation depends on a user opening attacker-delivered content inside Emacs on Android. No EPSS score was provided; the absence of a KEV listing and any known public exploit code suggests this is not currently under mass exploitation. The most severe outcome - arbitrary memory access - is explicitly bounded to 32-bit targets, which is a meaningful constraint as 64-bit Android devices dominate the market. The 'Google' tag in the intelligence data may indicate Google security team involvement in discovery or coordination, but this is not confirmed from the available sources. Overall, the real-world risk is moderate: the attack surface is niche (Emacs Android users), the highest-severity outcome requires a 32-bit device, and no active exploitation is identified.

An attacker crafts a malformed OpenType font file in which the table directory header claims a larger entry count than the file actually contains, then embeds this font in an HTML email viewed in Emacs, a webpage served to an EWW user, or a document with a custom face definition. When the Emacs for Android user opens the content, sfnt_read_table_directory() processes the inflated count, returns a struct populated with uninitialized heap memory in the excess entries, and subsequent font table lookups operate on that attacker-influenced data - leaking heap contents on most targets, or enabling memory corruption on 32-bit devices. No public proof-of-concept code is known at time of analysis.