Sean Whitton [21/Aug 2:33pm +01] wrote: Bas Alberts of the GitHub Security Lab discovered a local command execution vulnerability in GNU Emacs 30.2 onwards, and possibly earlier. This has been assigned CVE-2026-79992, with thanks to Marco Benatto.

-- Sean Whitton

GNU Emacs before 31.0.91 contains an integer overflow in the PBM/PPM/PGM image loader that allows an attacker to leak heap memory contents by supplying a crafted image with large dimensions and an elevated max color index. The image loader multiplies image dimensions and channel count using signed integer arithmetic; for sufficiently large values, the result wraps to a negative number, bypassing the bounds check and causing the pixel reader to access heap memory past the end of the allocated buffer. The over-read contents are interpreted as pixel color values and rendered on screen.

On 8/19/26 23:09, Sam James wrote: Eshel Yaron has shared an arbitrary code execution bug in GNU Emacs exploitable upon opening an file. It affects >= Emacs 28.1.

The reporter has a writeup at https://eshelyaron.com/posts/2026-08-06-emacs-arbitrary-code-execution-returns.html. It's from the same reporter as CVE-2024-53920 [0].

Thread on emacs-devel: https://lists.gnu.org/archive/html/emacs-devel/2026-07/msg00453.html https://lists.gnu.org/archive/html/emacs-devel/2026-08/msg00000.html

There's a workaround patch available for Emacs 31 (https://cgit.git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-31&id=8466eb44991707d128110bdc549fad14c8e1d61e) while on master it apparently had a bigger rework (https://cgit.git.savannah.gnu.org/cgit/emacs.git/commit/?id=c1337758a6c00e22e2a685e0556068fd73fa9a54).

In Gentoo, we backported the fix [1] down to 28.2.

[0] https://www.openwall.com/lists/oss-security/2025/02/26/2 [1] https://bugs.gentoo.org/980616

thanks, sam Disabling file-local variables seems to be an alternative mitigation, and the one I recommend. I would not be surprised if LLMs start popping out lots of 0day exploits in Emacs. -- Sincerely, Demi Marie Obenour (she/her/hers)

Eshel Yaron has shared an arbitrary code execution bug in GNU Emacs exploitable upon opening an file. It affects >= Emacs 28.1.

The reporter has a writeup at https://eshelyaron.com/posts/2026-08-06-emacs-arbitrary-code-execution-returns.html. It's from the same reporter as CVE-2024-53920 [0].

Thread on emacs-devel: https://lists.gnu.org/archive/html/emacs-devel/2026-07/msg00453.html https://lists.gnu.org/archive/html/emacs-devel/2026-08/msg00000.html

There's a workaround patch available for Emacs 31 (https://cgit.git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-31&id=8466eb44991707d128110bdc549fad14c8e1d61e) while on master it apparently had a bigger rework (https://cgit.git.savannah.gnu.org/cgit/emacs.git/commit/?id=c1337758a6c00e22e2a685e0556068fd73fa9a54).

In Gentoo, we backported the fix [1] down to 28.2.

[0] https://www.openwall.com/lists/oss-security/2025/02/26/2 [1] https://bugs.gentoo.org/980616

thanks, sam

A flaw was found in GNU Emacs. This vulnerability, a memory corruption issue, occurs when Emacs processes specially crafted SVG (Scalable Vector Graphics) CSS (Cascading Style Sheets) data. A local user could exploit this by convincing a victim to open a malicious SVG file, which may lead to a denial of service (DoS) or potentially information disclosure.

Off-by-one heap buffer overflow and uninitialized heap read in GNU Emacs src/image.c svgloadimage() when processing SVG CSS. The null terminator is written one byte past the allocation. Affected: Emacs 28.1 through 30.2. Fixed upstream on emacs-30: commit 8f535370b9.

Public bug: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=80851

A command injection flaw was found in the text editor Emacs. It could allow a remote, unauthenticated attacker to execute arbitrary shell commands on a vulnerable system. Exploitation is possible by tricking users into visiting a specially crafted website or an HTTP URL with a redirect.

A shell injection vulnerability exists in GNU Emacs due to improper handling of custom "man" URI schemes. Initially considered low severity, as it required user interaction with local files, it was later discovered that an attacker could exploit this vulnerability by tricking a user into visiting a specially crafted website or an HTTP URL with a redirect, leading to arbitrary shell command execution without further user action.This issue affects all released versions of GNU Emacs, including version 29.4.

Upstream patch: https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=820f0793f0b46448928905552726c1f1b999062f

In elisp-mode.el in GNU Emacs through 30.0.92, a user who chooses to invoke elisp-completion-at-point (for code completion) on untrusted Emacs Lisp source code can trigger unsafe Lisp macro expansion that allows attackers to execute arbitrary code. (This unsafe expansion also occurs if a user chooses to enable on-the-fly diagnosis that byte compiles untrusted Emacs Lisp source code.)

In elisp-mode.el in GNU Emacs before 30.1, a user who chooses to invoke elisp-completion-at-point (for code completion) on untrusted Emacs Lisp source code can trigger unsafe Lisp macro expansion that allows attackers to execute arbitrary code. (This unsafe expansion also occurs if a user chooses to enable on-the-fly diagnosis that byte compiles untrusted Emacs Lisp source code.)

Russ Allbery: In order to disable automatic previewing of org-mode attachments, you need to customize mm-automatic-display to remove text/x-org from the list of MIME types that are automatically previewed. (This part I have not tested.) As far as I understand it, this only controls inline vs attachment rendering. Content-Disposition: inline MIME parts are still displayed automatically, even if corresponding entries have been removed from mm-automatic-display.

I looked at this and as far as I can tell, to disable rendering, you have to remove entries from mm-inline-media-tests. I don't think this is possible through customization because the variable has bytecode objects in it.

I think it should be possible to filter it down, with something like the code below. Some comments on the choices: Patch rendering is just too useful to skip. HTML rendering is necessary (and obviously quite risky) because Jira and other tools do not generate useful plaintext mail.

It seems necessery to add explicit ignore entries for text/enriched and text/richtext because mm-inline-text handles those internally. The regexp may be required because it's possible that text/enriched/… could be used to bypass the subtype extraction in mm-handle-media-subtype. I haven't tested any of this.

(require 'mm-decode) (let ((result nil) (tail mm-inline-media-tests)) (while tail (let ((type-selector (caar tail)) (handler (cadar tail))) (when (or (eq handler 'ignore) (and (eq handler 'mm-inline-text) (not (member type-selector '("text/enriched" "text/richtext")))) (member type-selector '("image/p?jpeg" "image/png" "image/gif" "text/plain" "text/x-diff" "application/x-patch" "text/html"))) (push (car tail) result))) (setq tail (cdr tail))) (setq result (nreverse result)) (push '("text/enriched." ignore ignore) result) (push '("text/richtext." ignore ignore) result) (setq mm-inline-media-tests result))

I've put these into ~/.gnus.el for now, but having them in ~/.emacs might be a better option for other uses of Emacs MIME rendering.

Thanks, Florian

GNU Emacs could allow a remote attacker to execute arbitrary code on the system, caused by a code injection flaw in org-link-expand-abbrev in lisp/ol.el. By sending a specially crafted request, an attacker could exploit this vulnerability to execute arbitrary code on the system.

GNU Emacs could provide weaker than expected security, caused by an issue with LaTeX preview is enabled by default for e-mail attachments. A remote attacker could exploit this vulnerability to launch further attacks on the system.

GNU Emacs could provide weaker than expected security, caused by an issue with treating inline MIME contents as trusted. A remote attacker could exploit this vulnerability to launch further attacks on the system.

GNU Emacs could provide weaker than expected security, caused by an issue with contents of remote files to be trusted in Org mode. A remote attacker could exploit this vulnerability to launch further attacks on the system.

In Emacs before 29.3, arbitrary Lisp code is evaluated as part of turning on Org mode. This affects Org Mode before 9.6.23.

A flaw was found in the Emacs text editor. Processing a specially crafted org-mode code with the "org-babel-execute:latex" function in ob-latex.el can result in arbitrary command execution. This CVE exists because of a CVE-2023-28617 security regression for the emacs package in Red Hat Enterprise Linux 8.8 and Red Hat Enterprise Linux 9.2.

emacsclient-mail.desktop in Emacs 28.1 through 28.2 is vulnerable to Emacs Lisp code injections through a crafted mailto: URI with unescaped double-quote characters. It is fixed in 29.0.90.

emacsclient-mail.desktop in Emacs 28.1 through 28.2 is vulnerable to shell command injections through a crafted mailto: URI. This is related to lack of compliance with the Desktop Entry Specification. It is fixed in 29.0.90

An issue was discovered in GNU Emacs through 28.2. htmlfontify.el has a command injection vulnerability. In the hfy-istext-command function, the parameter file and parameter srcdir come from external input, and parameters are not escaped. If a file name or directory name contains shell metacharacters, code may be executed.

https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=1b4dc4691c1f87fc970fbe568b43869a15ad0d4c

GNU Emacs through 28.2 allows attackers to execute commands via shell metacharacters in the name of a source-code file, because lib-src/etags.c uses the system C library function in its implementation of the etags program. For example, a victim may use the "etags -u " command (suggested in the etags documentation) in a situation where the current working directory has contents that depend on untrusted input.

https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=01a4035c869b91c153af9a9132c87adb7669ea1c

An issue was discovered in GNU Emacs through 28.2. In ruby-mode.el, the ruby-find-library-file function has a local command injection vulnerability. The ruby-find-library-file function is an interactive function, and bound to C-c C-f. Inside the function, the external command gem is called through shell-command-to-string, but the feature-name parameters are not escaped. Thus, malicious Ruby source files may cause commands to be executed.

https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=9a3b08061feea14d6f37685ca1ab8801758bfd1c

GNU Emacs through 28.2 allows attackers to execute commands via shell metacharacters in the name of a source-code file, because lib-src/etags.c uses the system C library function in its implementation of the etags program. For example, a victim may use the "etags -u " command (suggested in the etags documentation) in a situation where the current working directory has contents that depend on untrusted input.