CVE-2026-71391 in Emacs
Summary
by MITRE • 08/10/2026
GNU Emacs for Android contains an off-by-one error in the gvar table parser in src/sfnt.c. The shared-coordinate index boundary check in sfnt_vary_simple_glyph() and sfnt_vary_compound_glyph() uses a strict greater-than comparison instead of greater-than-or-equal, allowing a crafted TrueType variable font to bypass the check and trigger a heap-based out-of-bounds read via memcpy. An attacker can deliver a malicious font file via email, EWW (Emacs Web Wowser), or documents with custom faces, causing Emacs to load it. This exposes heap memory contents which can be later used to defeat ASLR.
This issue was fixed in commit 95ab9ef627b212d74d321c5bbb5b56a1be7b9fbe
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/10/2026
The vulnerability described represents a critical security flaw in GNU Emacs for Android that stems from improper boundary validation within the font parsing subsystem. This issue manifests as an off-by-one error in the gvar table parser located in src/sfnt.c, specifically affecting how shared-coordinate index boundaries are checked during glyph processing. The technical root cause lies in the use of a strict greater-than comparison rather than a greater-than-or-equal comparison within the sfnt_vary_simple_glyph() and sfnt_vary_compound_glyph() functions, creating a condition where crafted TrueType variable fonts can bypass intended security checks.
The operational impact of this vulnerability extends beyond simple memory access violations to encompass significant security implications including potential information disclosure through heap-based out-of-bounds read operations. When Emacs processes malicious font files through its document rendering capabilities, the flawed boundary checking allows attackers to manipulate memory access patterns that result in reading data from adjacent heap locations. This particular vector is particularly concerning because it can be exploited through multiple delivery mechanisms including email attachments, web content loaded via EWW (Emacs Web Wowser), or documents containing custom font faces that Emacs renders automatically.
The exploitability of this vulnerability aligns with common attack patterns documented in the ATT&CK framework under software exploitation techniques, specifically targeting application-level vulnerabilities in document processing components. The flaw demonstrates characteristics consistent with CWE-129: Improper Validation of Array Index, where insufficient boundary checks allow access to memory outside intended allocation boundaries. The security implications are exacerbated by the fact that this vulnerability can be triggered automatically during normal document processing operations, making it particularly dangerous for end users who may unknowingly encounter malicious content.
The fix implemented in commit 95ab9ef627b212d74d321c5bbb5b56a1be7b9fbe addresses the core validation issue by correcting the boundary comparison logic to properly enforce inclusive bounds checking. This remediation ensures that shared-coordinate index values cannot exceed the allocated array boundaries, preventing the out-of-bounds memory access that previously enabled information disclosure attacks. The solution represents a standard defensive programming approach that aligns with industry best practices for preventing buffer overflows and related memory safety issues.
This vulnerability highlights the critical importance of proper boundary validation in font parsing libraries, as similar flaws have been documented in other applications including web browsers and office suites. The heap-based information disclosure aspect particularly threatens modern exploit mitigation techniques such as ASLR (Address Space Layout Randomization), since exposure of heap memory contents can reveal memory layout information that attackers can use to bypass security protections. The fix demonstrates the necessity of comprehensive testing and validation of parsing logic, especially in components that handle untrusted input from external sources through common user interaction pathways like email clients or web browsers within text editors.
The broader implications extend to mobile application security considerations, as Android applications that process rich text documents or custom fonts face similar risks when implementing font rendering functionality. This vulnerability serves as a reminder of the critical need for robust input validation in multimedia processing components and the importance of adhering to secure coding practices that prevent memory safety issues in complex parsing operations. The remediation approach taken in this fix exemplifies standard security hardening techniques that should be applied across similar font processing implementations in other software ecosystems.