CVE-2026-71394 in Emacs
Summary
by MITRE • 08/10/2026
GNU Emacs for Android improperly validates the table header input in sfnt_read_table_directory() in src/sfnt.c. Due to an incorrect comparison variable in the read-length check, a crafted font file that claims to contain more table directory entries than actually present causes the parser to return a struct with uninitialized heap memory in the table directory entries. 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 leads to the use of uninitialized heap data in subsequent table lookups, potentially resulting in information disclosure, crashes, or arbitrary memory access on 32-bit targets.
This issue is fixed after commit 7621ee1d01229d50e5c0cddea6bf0b01095a62cf
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/10/2026
The vulnerability in GNU Emacs for Android represents a critical heap-based buffer overflow condition that arises from improper input validation within the sfnt_read_table_directory() function located in src/sfnt.c. This flaw stems from an incorrect comparison variable during the read-length check process, which creates a fundamental mismatch between the claimed and actual number of table directory entries in font files. The vulnerability specifically affects the parsing of OpenType and TrueType font formats through the sfnt (Scalable Font) library component that Emacs uses for font handling.
The technical implementation of this flaw occurs when a maliciously crafted font file attempts to deceive the parser by declaring more table directory entries than are actually present in the file structure. The incorrect comparison variable causes the system to allocate memory based on the inflated count while only populating the actual number of entries, leaving the remaining heap memory uninitialized. This uninitialized data then gets stored within the table directory entry structures and subsequently accessed during later operations, creating a dangerous scenario where unpredictable values could be read from memory locations that were never properly initialized.
The operational impact of this vulnerability extends across multiple attack vectors that leverage Emacs's font processing capabilities. An attacker can deliver malicious font files through conventional email attachments, utilize Emacs Web Wowser (EWW) for web browsing with embedded malicious fonts, or include custom faces within documents that trigger the vulnerable parsing code path. The exploitation potential increases significantly on 32-bit targets where memory layout and addressing constraints make arbitrary memory access more feasible. This vulnerability aligns with CWE-457: Use of Uninitialized Variable, which specifically addresses scenarios where uninitialized memory is accessed, potentially leading to information disclosure or system instability.
The security implications of this vulnerability encompass multiple attack patterns documented in the MITRE ATT&CK framework, particularly those related to privilege escalation and code execution through software supply chain compromises. The ability to cause information disclosure through uninitialized heap data access represents a significant concern for systems where Emacs processes untrusted font content from external sources. Additionally, the potential for crashes and arbitrary memory access on 32-bit platforms creates opportunities for more sophisticated exploitation techniques that could lead to complete system compromise.
The mitigation strategy involves applying the fix implemented in commit 7621ee1d01229d50e5c0cddea6bf0b01095a62cf, which corrects the comparison variable issue and ensures proper validation of table directory entry counts against actual file content. Organizations should also implement defensive measures such as restricting font processing in sensitive environments, employing sandboxing techniques for document processing, and ensuring all Emacs installations receive timely security updates. The fix addresses the root cause by implementing proper bounds checking that validates claimed versus actual table entry counts before proceeding with memory allocation and initialization operations. This vulnerability demonstrates the importance of rigorous input validation in graphics libraries and font parsers where malformed inputs can lead to memory corruption issues that compromise system integrity and confidentiality.