GNU Emacs CVE-2026-71393

Exploitation requires all of the following to be simultaneously true: (1) the target is running GNU Emacs for Android as a 32-bit process - the integer overflow wrapping behavior is specific to 32-bit arithmetic and does not occur in 64-bit builds where size calculations use wider types; (2) the victim passively interacts with attacker-controlled content that causes Emacs to invoke sfnt_read_name_table() on the malicious font - specifically, opening or previewing an HTML email with an embedded crafted font in a mail client within Emacs (e.g., Rmail, Gnus, mu4e), browsing a page containing the font via EWW (Emacs Web Wowser), or opening a document that specifies a custom font face referencing the malicious file; (3) no prior authentication or elevated privileges are required from the attacker. Exploitation is concretely limited by: the 32-bit-only arithmetic constraint (most modern Android devices running 64-bit Emacs builds are not affected); the passive user interaction requirement (a victim must open or preview the malicious content - this is not a zero-click vulnerability); and Android's heap allocator hardening (scudo/tcmalloc), which significantly raises the practical bar for turning heap corruption into reliable code execution. No special server-side daemon, open port, or non-default Emacs configuration is required - the vulnerability is triggered entirely by the client-side TrueType font parsing path, which is active whenever Emacs renders content using sfnt.

The official CVSS 4.0 score of 5.3 (Medium) with vector AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:L/SC:N/SI:L/SA:N is notably conservative relative to the description's stated 'potential code execution' and the RCE tag. The scoring authority assessed only low availability impact on the vulnerable system and low subsequent-system integrity impact, suggesting they did not treat reliable RCE as a confident outcome - likely reflecting the fact that practical exploitation of heap overflows on modern Android is constrained by heap hardening (e.g., scudo, tcmalloc variants used in Android), ASLR, and the non-deterministic heap layout. No EPSS data was provided, preventing a probabilistic exploitation estimate. The vulnerability is not in CISA KEV, and no public exploit or proof-of-concept code has been identified at time of analysis, despite the 'RCE' tag in the intelligence data - tags should be treated as potential impact descriptors, not exploitation confirmations. The 32-bit-only constraint meaningfully limits the affected population: modern Android devices and many Emacs-for-Android installations running as 64-bit processes are not vulnerable. The UI:P (passive user interaction) requirement means the attack surface is real but not zero-click - a victim must open or preview attacker-controlled content. Overall, this is a medium-real-world-risk issue: meaningful to 32-bit Emacs-for-Android users who handle untrusted fonts or email, but not a broad enterprise priority given the niche deployment footprint.

An attacker crafts a TrueType font file with a malformed name table length field chosen to trigger integer overflow wrap-around in a 32-bit sfnt_read_name_table() calculation, producing a heap allocation far smaller than the data to be written. The attacker embeds the font in an HTML email and sends it to a victim using GNU Emacs for Android on a 32-bit device; when the victim opens or previews the email, Emacs loads the font to render the message, triggering the heap overflow and potentially corrupting adjacent heap metadata or function pointers. If the heap layout is favorable, this overflow could be leveraged for arbitrary code execution within the Emacs process on the Android device.