CVE-2026-94184: 
Linux Debian Analyse et atténuation des vulnérabilités

CVE-2026-94184 is a stack-based buffer overflow vulnerability in fetchmail's NTLM authentication code, affecting versions v5.0.8 through v6.6.6 when built with NTLM support (--enable-NTLM). A malicious or compromised mail server can send a crafted NTLM Type 2 challenge that causes fetchmail to write past a fixed 1024-byte stack buffer in ntlm_helper() / buildSmbNtlmAuthResponse() (in smbutil.c), potentially enabling remote code execution. The vulnerability was publicly disclosed on June 27, 2026 via the oss-security mailing list by fetchmail maintainer Matthias Andree, with the CVE published on September 21, 2026. It carries a CVSS v3.1 base score of 8.1 (High) (Red Hat CVE, GitHub Advisory, Openwall).

The root cause is CWE-121 (Stack-based Buffer Overflow): the AddBytes macro in fetchmail's NTLM client code copies server-supplied data from a Type 2 NTLM challenge into a fixed 1024-byte stack buffer without validating remaining capacity, allowing approximately 52 bytes to be written past the buffer boundary. Exploitation requires the attacker to control or compromise a mail server that fetchmail connects to and that advertises NTLM authentication — fetchmail must also have been compiled with --enable-NTLM. The overrun's practical impact depends on compiler stack-frame layout and hardening features: with stack smashing protection (SSP) or similar mitigations, the likely outcome is authentication failure or process abort rather than code execution. The fix was committed to the fetchmail GitLab repository (commit cb5be5c38471eec19e519ace0bc569176317ea92) and released in version 6.6.7 (Red Hat Bugzilla, Openwall).

Successful exploitation by an attacker controlling a mail server could result in remote code execution within the fetchmail process, granting full confidentiality, integrity, and availability impact on the affected host. Under memory hardening (e.g., SSP, FORTIFY_SOURCE), the practical outcome is more likely authentication failure or process termination (denial of service). Red Hat Enterprise Linux builds that enable NTLM and ship affected versions are specifically noted as impacted (Red Hat CVE, Red Hat Bugzilla).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the time of disclosure (Feedly). The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation is rated non-automatable (SSVC) due to the requirement that the attacker control or compromise a mail server that the victim's fetchmail instance connects to, and that the fetchmail binary was compiled with NTLM support. The vulnerability was originally reported by researcher Tristan Madani (Red Hat CVE, Openwall).

1. Identify target: Locate systems running fetchmail compiled with +NTLM support (verifiable via fetchmail -V | head -1), targeting versions 5.0.8 through 6.6.6.
2. Control or compromise a mail server: Set up or compromise a POP3/IMAP mail server that the target fetchmail instance is configured to poll, enabling the attacker to control NTLM authentication responses.
3. Advertise NTLM authentication: Configure the malicious mail server to advertise NTLM as a supported authentication mechanism so fetchmail initiates the NTLM handshake.
4. Send crafted Type 2 challenge: During the NTLM handshake, respond with a crafted Type 2 challenge message containing oversized fields (e.g., extremely long domain or server name fields) that exceed the 1024-byte stack buffer in buildSmbNtlmAuthResponse().
5. Trigger buffer overflow: The AddBytes macro copies the oversized data without bounds checking, overwriting approximately 52 bytes past the stack buffer boundary in ntlm_helper().
6. Achieve code execution or DoS: Depending on stack-frame layout and compiler hardening, the overwrite may redirect execution flow for RCE, or trigger stack canary detection causing process abort (Red Hat Bugzilla, Openwall).

• Process: Unexpected termination or crash of the fetchmail process, particularly during mail retrieval from servers using NTLM authentication; core dumps from fetchmail with stack corruption signatures.
• Logs: Fetchmail log entries showing NTLM authentication failures or abrupt session termination; syslog entries indicating segmentation faults or stack smashing detected (*** stack smashing detected ***) from the fetchmail process.
• Network: Unusual NTLM Type 2 challenge messages with abnormally large field lengths observed in network traffic between fetchmail and the mail server.
• File System: Presence of core dump files (e.g., core, core.fetchmail) in the working directory or configured core dump location following fetchmail crashes.

The primary fix is to upgrade fetchmail to version 6.6.7 or later, which includes the security patch (commit cb5be5c38471eec19e519ace0bc569176317ea92) that adds bounds checking to the NTLM buffer handling. As an immediate workaround, rebuild fetchmail without --enable-NTLM (omit NTLM at configure time) and confirm with fetchmail -V that the output does not list +NTLM. Alternatively, use the --auth PARAM option to specify a non-NTLM authentication mechanism supported by both fetchmail and the mail server. Additional mitigations include connecting only to trusted mail servers and implementing network segmentation to limit fetchmail's mail server connectivity (Red Hat CVE, Openwall).

The vulnerability was publicly disclosed by fetchmail maintainer Matthias Andree on the oss-security mailing list on June 27, 2026, who noted that NTLM is already discouraged due to weak cryptography and disabled by default, but binary packages (including Red Hat Enterprise Linux) may enable it for compatibility. Andree also noted that fetchmail 7 will remove NTLM support entirely, aligning with Microsoft's own guidance to deprecate NTLM in favor of Kerberos. Red Hat issued a preliminary CVSS assessment and mitigation guidance, noting that reliable RCE is constrained by compiler stack-frame layout and hardening features (Openwall, Red Hat CVE).