On Thu, 20 Aug 2026 04:09:29 +0100 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 CVE-2026-96269 was assigned to this issue yesterday.
-- Tomas Hoger / Red Hat Product Security
On Tue, 22 Sep 2026 15:11:54 +0000 Bas Alberts wrote: Is GitHub going to assign a CVE here? I think GitHub assignment would be ok per this part of the GitHub CNA scope definition: "vulnerabilities affecting open source projects discovered by security researchers at GitHub or Microsoft not covered by another CNA’s scope."
If GitHub is not doing assignment, Red Hat can provide it instead. If Red Hat could provide the CVE in line with the previous finding of this report batch (CVE-2026-79992) that would be greatly appreciated. CVE-2026-96442 was assigned for this issue.
-- Tomas Hoger / Red Hat Product Security
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.
Is GitHub going to assign a CVE here? I think GitHub assignment would be ok per this part of the GitHub CNA scope definition: "vulnerabilities affecting open source projects discovered by security researchers at GitHub or Microsoft not covered by another CNA’s scope."
If GitHub is not doing assignment, Red Hat can provide it instead. If Red Hat could provide the CVE in line with the previous finding of this report batch (CVE-2026-79992) that would be greatly appreciated.
Thanks, Bas
On Mon, 14 Sep 2026 11:47:17 +0100 Sean Whitton wrote: Bas Alberts of the GitHub Security Lab discovered that the fix for CVE-2024-53920, an arbitrary code execution flaw in Emacs, was incomplete. Viewing or editing untrusted text files in modes other than Emacs Lisp mode can also permit arbitrary code execution. For example:
#!/usr/bin/perl # -- mode: perl; mode: flymake -- BEGIN { system("touch uhoh.txt"); }
This problem affects all Emacs versions affected by CVE-2024-53920. This means Emacs 24 and newer, and possibly also older versions.
A minimal fix, attached, is queued up for release with Emacs 31.2. We (the Emacs upstream maintainers) don't expect to backport the fix to older Emacs releases ourselves.
This fix is more aggressive than the one we have on our master branch in that it also implicitly disables the Eglot flymake backend. I think we will be able to undo that before releasing Emacs 31.2, but I wanted to get this notification out as soon as possible.
I would be grateful if someone could assign us a CVE for this issue. Is GitHub going to assign a CVE here? I think GitHub assignment would be ok per this part of the GitHub CNA scope definition: "vulnerabilities affecting open source projects discovered by security researchers at GitHub or Microsoft not covered by another CNA’s scope."
If GitHub is not doing assignment, Red Hat can provide it instead.
-- Tomas Hoger / Red Hat Product Security
A code execution flaw was found in Emacs, affecting versions prior to 31.2. The Flymake mode using language backends other than Lisp would execute arbitrary code from the edited file while performing syntax checking. Viewing or editing untrusted files using Emacs could lead to arbitrary code execution with the privileges of the user running Emacs.
Emacs upstream reports:
Bas Alberts of the GitHub Security Lab discovered that the fix for CVE-2024-53920, an arbitrary code execution flaw in Emacs, was incomplete. Viewing or editing untrusted text files in modes other than Emacs Lisp mode can also permit arbitrary code execution. For example:
#!/usr/bin/perl # -- mode: perl; mode: flymake -- BEGIN { system("touch uhoh.txt"); }
This problem affects all Emacs versions affected by CVE-2024-53920. This means Emacs 24 and newer, and possibly also older versions.
A minimal fix, attached, is queued up for release with Emacs 31.2. We (the Emacs upstream maintainers) don't expect to backport the fix to older Emacs releases ourselves.
Source: https://www.openwall.com/lists/oss-security/2026/09/14/1
Upstream commit - emacs-31 branch: https://github.com/emacs-mirror/emacs/commit/abc802ee2eb0b1663349ddf22a461f8e54a383fb
Upstream commit - master branch: https://github.com/emacs-mirror/emacs/commit/135e6f63f08fee3d374fa1a5187bce941a2d3e3c
Bas Alberts of the GitHub Security Lab discovered that the fix for CVE-2024-53920, an arbitrary code execution flaw in Emacs, was incomplete. Viewing or editing untrusted text files in modes other than Emacs Lisp mode can also permit arbitrary code execution. For example:
#!/usr/bin/perl # -- mode: perl; mode: flymake -- BEGIN { system("touch uhoh.txt"); }
This problem affects all Emacs versions affected by CVE-2024-53920. This means Emacs 24 and newer, and possibly also older versions.
A minimal fix, attached, is queued up for release with Emacs 31.2. We (the Emacs upstream maintainers) don't expect to backport the fix to older Emacs releases ourselves.
This fix is more aggressive than the one we have on our master branch in that it also implicitly disables the Eglot flymake backend. I think we will be able to undo that before releasing Emacs 31.2, but I wanted to get this notification out as soon as possible.
I would be grateful if someone could assign us a CVE for this issue.
-- >8 -- From: Stefan Monnier <monnier () iro umontreal ca> Date: Mon, 14 Sep 2026 11:30:39 +0100 Subject: [PATCH] flymake.el: Generalize trusted-content-p check to all backends
Minimal safe backport of this change:
Author: Stefan Monnier <monnier () iro umontreal ca> AuthorDate: Fri Sep 11 21:48:55 2026 -0400
flymake.el: Generalize trusted-content-p check to all backends
Rather than have each and every backend check 'trusted-content-p' if it feels necessary, implement the check once and forall in flymake.el and provide a wat for backends to skip that test, so we replace an "opt-in" with an "opt-out" that's a bit more secure by design.
lisp/progmodes/elisp-mode.el (elisp-flymake-byte-compile): Move 'trusted-content-p' to flymake.el. lisp/progmodes/flymake.el (flymake--run-backend): Move 'trusted-content-p' from elisp-mode.el.
lisp/progmodes/eglot.el (eglot-flymake-backend): Mark as safe.
lisp/progmodes/flymake.el (flymake--run-backend): Copy trusted-content-p check from elisp-mode.el. Do not merge to master. --- lisp/progmodes/flymake.el | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/lisp/progmodes/flymake.el b/lisp/progmodes/flymake.el index fff42696761..40761031dc2 100644 --- a/lisp/progmodes/flymake.el +++ b/lisp/progmodes/flymake.el @@ -1271,8 +1271,13 @@ with a report function." (flymake--state-disabled state) nil (flymake--state-reported-p state) nil)) (condition-case-unless-debug err - (apply backend (flymake-make-report-fn backend run-token) - args) + (if (or (trusted-content-p) (function-get backend 'flymake-always-safe)) + (apply backend (flymake-make-report-fn backend run-token) + args) + (message "Disabling %S in %s (untrusted content)" + backend (buffer-name)) + (user-error "Disabling %S in %s (untrusted content)" + backend (buffer-name))) (error (flymake--disable-backend backend err))))) -- Sean Whitton
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 < 31.0.91 Heap Over-Read via PBM/PPM/PGM Image Loader
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.