CVE-2026-96442: Emacs Flymake Mode RCE Vulnerability

CVE-2026-96442 Overview

A code execution flaw affects GNU Emacs versions prior to 31.2. The Flymake on-the-fly syntax checker executes arbitrary code from the edited file when using language backends other than Emacs Lisp. Simply viewing or editing an untrusted file in Emacs can trigger arbitrary code execution with the privileges of the user running the editor. The issue stems from an incomplete trusted-content-p check that was applied only to the Emacs Lisp byte-compile backend, leaving other Flymake backends unguarded. The vulnerability is tracked under CWE-94: Improper Control of Generation of Code.

Critical Impact

Opening an attacker-crafted source file in Emacs is sufficient to execute arbitrary code as the current user, with no additional privileges required.

Affected Products

• GNU Emacs versions prior to 31.2
• Flymake mode using non-Lisp language backends
• Distributions shipping vulnerable Emacs builds (see Red Hat CVE-2026-96442 Advisory)

Discovery Timeline

• 2026-09-14 - Public discussion on OpenWall OSS-Security
• 2026-09-23 - CVE-2026-96442 published to NVD
• 2026-09-23 - Last updated in NVD database

Technical Details for CVE-2026-96442

Vulnerability Analysis

Flymake is the built-in Emacs framework for on-the-fly syntax checking. It dispatches diagnostics through pluggable backends, one per major mode. Before this fix, only the elisp-flymake-byte-compile backend checked whether the buffer's content was trusted through trusted-content-p. Backends for other languages invoked external tools or evaluated buffer content without any trust gate. An attacker who ships a source file containing directives, macros, or embedded compiler options that a backend passes to a checker process can achieve local code execution the moment the file is opened and Flymake activates.

Root Cause

The root cause is a missing, generalized trust check in the Flymake dispatcher lisp/progmodes/flymake.el. The trusted-content-p guard existed in elisp-flymake-byte-compile but was never applied when Flymake invoked arbitrary backends. Any backend that shells out to a language toolchain, such as compilers, linters, or LSP-adjacent helpers, inherited that gap and processed untrusted buffer content as if it were safe.

Attack Vector

Exploitation requires user interaction: the victim opens or edits a malicious file. No authentication or network access is needed because the attack executes locally in the user's Emacs session. Delivery vectors include cloned Git repositories, email attachments, shared project directories, and archives that place files on disk where the user later opens them. Once Flymake selects a vulnerable backend for the file's major mode, the crafted content is handed to a checker process, resulting in code execution under the user's account.

# Patched dispatcher in lisp/progmodes/flymake.el
(condition-case-unless-debug err
    (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)))
# Source: https://github.com/emacs-mirror/emacs/commit/abc802ee2eb0b1663349ddf22a461f8e54a383fb

The patch adds trusted-content-p and an opt-in flymake-always-safe property check around every backend invocation. A companion change in lisp/progmodes/eglot.el marks the Eglot backend as safe because it delegates to a language server rather than executing buffer content directly.

Detection Methods for CVE-2026-96442

Indicators of Compromise

• Unexpected child processes spawned by the emacs binary immediately after a file is opened, particularly compiler or interpreter processes such as cc, gcc, python, ruby, or node.
• New or modified files in the user's home directory or ~/.emacs.d/ shortly after opening a downloaded source file.
• Outbound network connections initiated by processes whose parent is emacs running in an interactive session.

Detection Strategies

• Monitor process ancestry for emacs parents launching shell interpreters or fetching remote content, which is atypical for routine editing.
• Alert on Flymake backend invocations that produce file writes outside build or cache directories associated with the current project.
• Correlate file-open events for untrusted paths (downloads, temp directories, shared mounts) with subsequent process creation under the user context.

Monitoring Recommendations

• Enable command-line auditing (auditd execve rules on Linux, EDR process telemetry on macOS) for developer workstations.
• Log Emacs version strings from managed endpoints to identify hosts still running versions prior to 31.2.
• Review *flymake log* buffers and system logs for Disabling <backend> in <buffer> (untrusted content) messages after patching, which indicate blocked execution attempts.

How to Mitigate CVE-2026-96442

Immediate Actions Required

• Upgrade GNU Emacs to version 31.2 or later on all workstations and build hosts.
• Until patched, disable Flymake globally with (global-flymake-mode -1) or avoid opening untrusted files in Emacs.
• Treat repositories, email attachments, and archives from external sources as untrusted, and inspect them in a sandboxed environment before editing.

Patch Information

The fix is delivered by upstream commits abc802ee and 135e6f63. The first generalizes trusted-content-p enforcement to every Flymake backend and introduces the flymake-always-safe opt-in property. The second marks eglot-flymake-backend as safe. Distribution updates are tracked in the Red Hat CVE-2026-96442 Advisory and Red Hat Bug Report #2537347.

Workarounds

• Add untrusted project directories to the deny list used by trusted-content so Flymake refuses to run backends on files under those paths.
• Open suspect files with emacs -Q to bypass user init, or use find-file-literally to prevent major-mode hooks from enabling Flymake.
• Run Emacs inside a container, bwrap sandbox, or dedicated non-privileged user account when reviewing code from untrusted sources.

# Verify the installed Emacs version and disable Flymake as a temporary workaround
emacs --version | head -n1

# Add to ~/.emacs or ~/.emacs.d/init.el to disable Flymake globally until patched
echo "(global-flymake-mode -1)" >> ~/.emacs.d/init.el