GNU Emacs, Gnus, and Org mode trust inline MIME content, enabling unsafe processing

In Emacs before 29.3, Gnus treats inline MIME contents as trusted.

• GNU Emacs: NVD lists versions before 29.3 as affected.
• GNU Org mode: NVD lists versions before 9.6.23 as affected. Project discussion states that external Org mode needs a corresponding change alongside the Emacs-side fix.
• Debian GNU/Linux 10.0: Listed as affected. Debian LTS published the fix in emacs package 1:26.1+1-3.2+deb10u5.
• Debian packages with confirmed fixes: The bullseye branch has the fix in emacs 1:27.1+1-3.1+deb11u3; the bookworm branch has it in 1:28.2+1-15+deb12u1; bookworm-backports has it in 1:29.3+1-2~bpo12+1.
• Org mode on Debian buster: 9.1.14+dfsg-3+deb10u2 was published with the fix and requires the corresponding Emacs package 1:26.1+1-3.2+deb10u5 for the complete change set.

At the affected boundary, Gnus renders inline MIME content but, before the patch series, did not mark that content as untrusted. The Emacs patch discussion identifies lisp/gnus/mm-view.el, specifically mm-display-inline-fontify, as the place where content is marked untrusted; the untrusted-content variable in lisp/files.el and an Org mode LaTeX-preview guard are related changes. The input can originate in email content or attachments. The project discussion names Gnus and MUAs that reuse Gnus libraries, including notmuch and mu4e; rmail was not believed to be affected, but that statement was qualified and is not a definitive exclusion. The modeled path requires local use of the client and user interaction, and the record does not establish exposure as a remote unauthenticated network service. A project maintainer stated that the Gnus commit associated with this record was not sufficient by itself; external Org mode also needed a corresponding change, so the precise vulnerable execution path and complete fix boundary remain subject to that coordination caveat.

• Reachability: Exploitation requires an Emacs session using Gnus or an MUA that reuses Gnus libraries, while MIME or email content is processed.
• Authentication and privileges: The supplied assessment models no prior privileges or separate authentication requirement for processing the content.
• User interaction: A user must open, display, or otherwise process the relevant content.
• Complexity: The assessment models low attack complexity.
• Status: The supplied record marks public_exploit as false and known_exploited as unspecified. This is record metadata, not proof that exploitation has never occurred. The sources reviewed do not name a specific exploit, campaign, victim, or incident.

The technical outcome can be email content entering processing intended for trusted data, with possible unsafe processing. Project discussions describe two consequences associated with the change series: code execution in one processing path and disk exhaustion in the LaTeX-processing path; the exact scope of this record remains disputed. The supplied assessment assumes no prior privileges, requires user interaction, and keeps the impact scope unchanged. The assessed consequence is primarily loss of availability, while no confidentiality or integrity impact is identified. The record does not establish automatic privilege escalation or impact on another system.

Crafted email or MIME content may be processed with a higher trust level than intended in a mail-reading workflow. Project discussion links the change series to processing that could execute code or exhaust disk space, but it does not provide a validated exploitation scenario specific to this record. Realistic operational consequences include an Emacs or MUA hang, resource consumption, local denial of service, or disruption requiring the user to restart the workflow. The supplied assessment focuses on availability impact and does not identify a confidentiality or integrity impact. The evidence reviewed does not name a specific campaign, victim, or breach.

1. Upgrade GNU Emacs to 29.3, the upstream release identified by the record as the fix boundary for earlier versions.
2. If external Org mode is deployed, upgrade it to 9.6.23 and ensure that both the Org mode and Emacs changes are installed. A fix on only one side does not demonstrate that every processing path is protected.
3. For Debian, install the fixed package for the deployed branch: buster 1:26.1+1-3.2+deb10u5; bullseye 1:27.1+1-3.1+deb11u3; bookworm 1:28.2+1-15+deb12u1; bookworm-backports 1:29.3+1-2~bpo12+1. For the buster Org mode package, use 9.1.14+dfsg-3+deb10u2 together with the corresponding Emacs package.
4. If an update is temporarily impossible, prefer the user-prompt protection for potentially unsafe resources where that protection is included in a distributor backport. The evidence reviewed does not confirm a universal configuration-only workaround.
5. Do not infer safety for parallel branches or other releases from a fix boundary established for one branch; continue checking the distributor's status for the deployed package.

1. Inventory GNU Emacs and Org mode versions on systems used for email reading, then compare each branch with the affected and fixed boundaries in affected_summary.
2. Identify systems using Gnus or an MUA that reuses Gnus libraries, especially notmuch and mu4e. Not finding rmail is not sufficient to conclude that a system is safe.
3. Review whether email workflows render inline MIME content or enable LaTeX preview, since these are the processing paths discussed in the technical sources.
4. Review logs and telemetry for unexpected Emacs LaTeX-processing subprocesses, unusual disk consumption, hangs, or resource exhaustion while displaying mail. This is precautionary monitoring, not a confirmed IOC.
5. Compare distribution changelogs with the exact fixed package for the deployed branch. The absence of log evidence or abnormal behavior does not prove that the system is unaffected.