fetchmail CVE-2026-94184

Requires fetchmail to be BUILT with NTLM support AND configured to use NTLM authentication against the attacker-controlled endpoint. The attacker must control, compromise, or MITM the mail server that fetchmail connects to (this is a malicious-server/client-side vulnerability, not a service-facing one). Exploitation is triggered automatically when fetchmail polls the hostile server, but reliable code execution is limited by stack-frame layout and defeated-or-downgraded-to-crash by memory hardening (stack canaries, ASLR, FORTIFY_SOURCE) present on modern RHEL builds. Not exploitable against fetchmail instances that do not use NTLM auth or that only connect to trusted servers over authenticated TLS.

This is a genuinely serious flaw but with meaningful preconditions that temper raw urgency. The CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H = 8.1) correctly captures the two defining traits: this is a 'reverse' or malicious-server attack (the mail SERVER attacks the fetchmail CLIENT via a crafted NTLM Type 2 challenge), and AC:H reflects that reliable RCE depends on stack-frame layout - the description itself hedges ('may lead to remote code execution depending on stack-frame layout, or to authentication failure or process termination under memory hardening'). On modern hardened builds (stack canaries, ASLR, FORTIFY_SOURCE) the realistic outcome is often a crash (availability impact) rather than code execution, so the C:H/I:H may be optimistic for RHEL 8/9/10 defaults. No EPSS score, no CISA KEV listing, and no public POC are provided in the input, so exploitation status is: no public exploit identified at time of analysis. No SSVC decision data is provided. Net: a real patch-worthy issue for anyone running fetchmail with NTLM against untrusted/compromisable servers, but NOT a drop-everything internet-wide emergency - exploitation requires the victim to poll a hostile server with NTLM auth enabled, which is a narrow configuration.

An attacker who controls or has compromised a mail server (or can MITM an unencrypted POP3/IMAP session) configures it to advertise NTLM authentication. When a victim's fetchmail - built with NTLM support and configured to use it - connects and polls, the server returns a crafted NTLM Type 2 challenge that overflows a fixed stack buffer as fetchmail builds the authenticate response, potentially executing code with the fetchmail user's privileges or crashing the process. No public exploit code is identified in the provided data.