Emacs Arbitrary Code Execution Returns
Created on [2026-08-06], last updated [2026-08-06]
It’s been over a year and a half since I last wrote here about an<br>arbitrary code execution vulnerability in Emacs. I guess the title<br>mostly gave it away, but yes, there’s another such vulnerability that<br>you should know about. This one’s actually pretty cool; it probably<br>deserves a lengthy deep dive. But for now, just a short PSA:
Commit 8466eb44, which landed on the emacs-31 release branch on<br>2026-08-05, mitigates an arbitrary-code-execution-on-file-open<br>vulnerability (CVE requested, not yet assigned). The vulnerability<br>abuses Emacs Lisp symbol shorthands, a feature added in Emacs 28.1.<br>It allows a specially-crafted file to trigger arbitrary<br>attacker-controlled Emacs Lisp code execution as soon as you open the<br>file—even before the file’s malicious contents are displayed.<br>Moreover, any file can carry the exploit, regardless of the file’s<br>name or extension. It does not require any special settings either;<br>the default configuration is vulnerable. Stefan Monnier posted a<br>proof of concept in the Emacs bug tracker.
This vulnerability affects all Emacs versions from 28.1 onward,<br>including 31.0.91, which is the latest pretest version of Emacs 31 as<br>of this writing. No released Emacs version currently has the<br>mitigation.
As far as I know, there are no plans to provide security releases for<br>existing Emacs versions (the subject came up in this discussion on the<br>emacs-devel mailing list). The mitigation is small and<br>self-contained, though—it binds read-symbol-shorthands to nil<br>around a few risky intern calls in two files—so it should apply<br>cleanly to previous Emacs versions. If you package (or just use) an<br>affected Emacs version, you may want to cherry-pick this commit.
If you can’t get an Emacs with this mitigation, but you are using<br>Emacs 30 or later, then another way to protect yourself is to install<br>and enable my trust-manager package. It includes a blunter solution<br>for this problem: in untrusted files, it disables symbol shorthands<br>altogether.
On all affected versions, you can approximate the emacs-31<br>mitigation without rebuilding Emacs, by adding something like the<br>following to your configuration:
(defun suppress-shorthands (orig &rest args)<br>(let (read-symbol-shorthands) (apply orig args)))
(advice-add 'vc-find-backend-function :around #'suppress-shorthands)
(with-eval-after-load 'cc-fonts<br>(advice-add 'c-compose-keywords-list :around #'suppress-shorthands))
On the Emacs master branch, this vulnerability has been fixed at a<br>more fundamental level by severing a risky connection between symbol<br>shorthands and interning symbols: intern and intern-soft no<br>longer consult read-symbol-shorthands (see bug#80574). This fix<br>will only appear in Emacs 32, though.