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 < 31.0.91 Heap Over-Read via PBM/PPM/PGM Image Loader
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
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
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
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.)
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
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
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.
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
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
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 ctags program. For example, a victim may use the "ctags " command (suggested in the ctags documentation) in a situation where the current working directory has contents that depend on untrusted input.
Emacs 21.2.1 does not prompt or warn the user before executing Lisp code in the local variables section of a text file, which allows user-assisted attackers to execute arbitrary commands, as demonstrated using the mode-name variable.
The make-temp-name Lisp function in Emacs 20 creates temporary files with predictable names, which allows attackers to conduct a symlink attack.
read-passwd and other Lisp functions in Emacs 20 do not properly clear the history of recently typed keys, which allows an attacker to read unencrypted passwords.
Emacs 20 does not properly set permissions for a slave PTY device when starting a new subprocess, which allows local users to read or modify communications between Emacs and the subprocess.
lisp/net/browse-url.el in GNU Emacs 24.3 and earlier allows local users to overwrite arbitrary files via a symlink attack on a /tmp/Mosaic.##### temporary file.
lisp/net/tramp-sh.el in GNU Emacs 24.3 and earlier allows local users to overwrite arbitrary files via a symlink attack on a /tmp/tramp.##### temporary file.
lisp/gnus/gnus-fun.el in GNU Emacs 24.3 and earlier allows local users to overwrite arbitrary files via a symlink attack on the /tmp/gnus.face.ppm temporary file.
lisp/emacs-lisp/find-gc.el in GNU Emacs 24.3 and earlier allows local users to overwrite arbitrary files via a symlink attack on a temporary file under /tmp/esrc/.
lib-src/movemail.c in movemail in emacs 22 and 23 allows local users to read, modify, or delete arbitrary mailbox files via a symlink attack, related to improper file-permission checks.
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.
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.)