CVE-2026-6861

GNU Emacs before 25.3 allows remote attackers to execute arbitrary code via email with crafted 'Content-Type: text/enriched' data. In particular, an Emacs user can be instantly compromised by reading a crafted email message.

GNU Emacs 28.1 through 31.1 allows arbitrary code execution upon opening a file, because an untrusted value of read-symbol-shorthands affects the intern and unintern functions. This affects the default configuration; no particular user settings are required to trigger it.

GNU Emacs before 31.0.91 has an integer overflow in the PBM/PPM/PGM image loader. An attacker can supply a crafted image with large dimensions and an elevated max color index, leading to heap memory content leakage.

GNU Emacs for Android improperly validates 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 can cause the parser to return a struct with uninitialized heap memory in table directory entries. This can lead to information disclosure, crashes, or arbitrary memory access on 32-bit targets.

GNU Emacs for Android is vulnerable to an integer overflow in sfnt_read_name_table() in src/sfnt.c. The function computes an allocation size using a 32-bit length value from a TrueType font file without overflow checking. On 32-bit targets, a crafted font causes the calculation to wrap, resulting in an undersized heap allocation and subsequent heap buffer overflow during read.

GNU Emacs for Android is vulnerable to an integer overflow in the sfnt_read_cmap_format_12() function in src/sfnt.c. When processing a crafted TrueType font file, an unguarded addition in the xmalloc allocation call wraps around on 32-bit builds, causing a heap buffer overflow write. This can lead to heap memory corruption and potential code execution.

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. This exposes heap memory contents which can be later used to defeat ASLR.

In elisp-mode.el in GNU Emacs before 30.1, invoking elisp-completion-at-point on untrusted Emacs Lisp source code can trigger unsafe Lisp macro expansion, allowing arbitrary code execution. This also occurs if on-the-fly byte compilation diagnosis is enabled.