Emacs arbitrary code execution and how to avoid it

Vulnerability & risk surface

• Opening an untrusted Emacs Lisp file with Flymake/Flycheck or using completion-at-point can trigger macro expansion that executes arbitrary code, even if the user only intends to inspect the file.
• The surprising part for many: code can run from completion and tooling, not just from explicitly evaluating or loading the file.
• Some see this as a serious, long-known flaw that should have been fixed years ago; others view it as one more instance of “don’t trust untrusted code.”

Proposed in-Emacs mitigations

• Disable macro expansion for completion in elisp buffers, accepting degraded completion quality.
• Add a configurable “paranoid elisp mode” or buffer-local flag that:
  • Disables macro expansion and eval from editing commands.
  • Blocks keybindings like eval-last-sexp when examining suspicious code.
• Mirror existing protections for file-local variables and org-babel: prompt before executing anything and offer a “never execute in this buffer” option.

Sandboxing & capability ideas

• Suggestions to offload macro expansion and analysis to:
  • A separate Emacs process.
  • An LSP server / external sandbox.
• Others mention OS-level sandboxes (Firejail, bubblewrap, userspace firewalls) as practical defenses, especially for always-on Emacs.
• Capability-based security for languages is raised, but participants note it’s hard to apply correctly and can create painful UX (frequent prompts, like OS permission dialogs).

Other editors & ecosystems

• Similar issues have existed in Vim via modelines; macros and runtime analysis in dynamic languages (Ruby, Python, JS) often require executing code.
• VSCode’s “workspace trust” model is praised, but its extension ecosystem is seen as a major malware vector.
• Several argue switching to Vim/Neovim for “security” is misguided given their own CVE history; only very simple editors are genuinely safer.

Threat model, prevalence & social aspects

• Some think this specific attack is low-probability compared to poisoning popular packages (MELPA, language registries).
• Others argue Emacs users are attractive, high-value targets and that few people audit Emacs security deeply.
• Disagreement exists on how much responsibility lies in tooling vs user behavior; one camp sees this as a social/trust problem, another wants technical hardening.

Emacs philosophy vs safety

• Strong emphasis that Emacs is essentially an interactive Lisp machine, not just an editor; arbitrary code execution and lack of sandboxing are fundamental to its power.
• Some accept the risk, preferring maximal extensibility and local control; others see Emacs’s age and architecture as a barrier to modern security expectations and consider migrating.