Emacs Arbitrary Code Execution Returns

It’s been over a year and a half since I last wrote here about an arbitrary code execution vulnerability in Emacs. I guess the title mostly gave it away, but yes, there’s another such vulnerability that you should know about. This one’s actually pretty cool; it probably deserves a lengthy deep dive. But for now, just a short PSA:

Commit 8466eb44, which landed on the emacs-31 release branch on 2026-08-05, mitigates an arbitrary-code-execution-on-file-open vulnerability (CVE requested, not yet assigned). The vulnerability abuses Emacs Lisp symbol shorthands, a feature added in Emacs 28.1. It allows a specially-crafted file to trigger arbitrary attacker-controlled Emacs Lisp code execution as soon as you open the file—even before the file’s malicious contents are displayed. Moreover, any file can carry the exploit, regardless of the file’s name or extension. It does not require any special settings either; the default configuration is vulnerable. Stefan Monnier posted a proof of concept in the Emacs bug tracker.

This vulnerability affects all Emacs versions from 28.1 onward, including 31.0.91, which is the latest pretest version of Emacs 31 as of this writing. No released Emacs version currently has the mitigation.

As far as I know, there are no plans to provide security releases for existing Emacs versions (the subject came up in this discussion on the emacs-devel mailing list). The mitigation is small and self-contained, though—it binds read-symbol-shorthands to nil around a few risky intern calls in two files—so it should apply cleanly to previous Emacs versions. If you package (or just use) an 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 Emacs 30 or later, then another way to protect yourself is to install and enable my trust-manager package. It includes a blunter solution for this problem: in untrusted files, it disables symbol shorthands altogether.

On all affected versions, you can approximate the emacs-31 mitigation without rebuilding Emacs, by adding something like the following to your configuration:

(defun suppress-shorthands (orig &rest args)
  (let (read-symbol-shorthands) (apply orig args)))

(advice-add 'vc-find-backend-function :around #'suppress-shorthands)

(with-eval-after-load 'cc-fonts
  (advice-add 'c-compose-keywords-list :around #'suppress-shorthands))

On the Emacs master branch, this vulnerability has been fixed at a more fundamental level by severing a risky connection between symbol shorthands and interning symbols: intern and intern-soft no longer consult read-symbol-shorthands (see bug#80574). This fix will only appear in Emacs 32, though.