Fedora Account System
Red Hat Associate
Red Hat Customer
This has been public for shy of three months. As Fedora is a CNA and I am a lone wolf maintaining fetchmail, please assign a CVE ID. The issue has been public since 2026 June 27 and was announced via oss-security@ and the fetchmail lists. The current stable reference for the VULN is fetchmail-SA-2026-01. I tried to get a CVE ID from MITRE, which failed. ------------- fetchmail 6.6.6 can become vulnerable to a remote code execution in the NTLM client depending on how the compiler lays out the stack. See the https://www.fetchmail.info/fetchmail-SA-2026-01.txt for details. Please update to 6.6.7 or better 6.6.8.rc1 (which also adds a new zh_TW translation, traditional Chinese) and updates the NEWS file which, in 6.6.7, believed the bug to be non-exploitable. Since the application cannot control the stack layout, we need to have the fix. 6.6.7.rc1, rc2, rc3, the 6.6.7 release and 6.6.8.rc1 all have an additional size guard in place that avoids the stack buffer overrun. Please backport to F43 and forward-port to F45 and Rawhide. Consider to disable all optional MD5-based authentication schemes in the .spec file, Reproducible: Always Steps to Reproduce: This is a source code vulnerability that would require a server to be maliciously compromised. Actual Results: fetchmail can crash and a few dozen bytes can be injected on the stack including the return address. Expected Results: no vulnerability in NTLM authentication code (ntlm_helper(), in particular)
Just figured that the po/LINGUAS file lacks the "sr" word, which means the sr_RS.UTF-8 translation will not be installed. It's already present in 6.6.7 (but updated in 6.6.8.rc1) so you may want to patch the po/LINGUAS file so that on the non-commented line you'll have "sq sr sv" where there is now "sq sv"
FEDORA-2026-babb1758d0 (fetchmail-6.6.7-1.fc45) has been submitted as an update to Fedora 45. https://bodhi.fedoraproject.org/updates/FEDORA-2026-babb1758d0
FEDORA-2026-5e046af160 (fetchmail-6.6.7-1.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-5e046af160
FEDORA-2026-2fa3830469 (fetchmail-6.6.7-1.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2026-2fa3830469
FEDORA-2026-2fa3830469 has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-2fa3830469` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-2fa3830469 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-babb1758d0 has been pushed to the Fedora 45 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-babb1758d0` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-babb1758d0 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-5e046af160 has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-5e046af160` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-5e046af160 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
(In reply to Matthias Andree from comment #0) > This has been public for shy of three months. > > As Fedora is a CNA and I am a lone wolf maintaining fetchmail, please assign > a CVE ID. > > The issue has been public since 2026 June 27 and was announced via > oss-security@ and the fetchmail lists. The current stable reference for the > VULN is fetchmail-SA-2026-01. > > I tried to get a CVE ID from MITRE, which failed. Hello Matthias, Regarding the CVE ID: I asked Red Hat Product Security and was pointed to secalert, which is the documented CNA contact covering both the Red Hat and the Fedora Project CNA scopes -- see https://access.redhat.com/security/team/contact and https://access.redhat.com/articles/red_hat_cve_program. I sent the request there yesterday with the details from fetchmail-SA-2026-01 v1.1. You are welcome to write to that address directly as well. > ------------- > > fetchmail 6.6.6 can become vulnerable to a remote code execution in the NTLM > client depending on how the compiler lays out the stack. See the > https://www.fetchmail.info/fetchmail-SA-2026-01.txt for details. > > Please update to 6.6.7 or better 6.6.8.rc1 (which also adds a new zh_TW > translation, traditional Chinese) and updates the NEWS file which, in 6.6.7, > believed the bug to be non-exploitable. Since the application cannot > control the stack layout, we need to have the fix. 6.6.7.rc1, rc2, rc3, the > 6.6.7 release and 6.6.8.rc1 all have an additional size guard in place that > avoids the stack buffer overrun. > > Please backport to F43 and forward-port to F45 and Rawhide. > > Consider to disable all optional MD5-based authentication schemes in the > .spec file, > Fedora packages have been updated to 6.6.7 on all branches. In Rawhide I have additionally disabled the optional MD4/MD5-based authentication schemes NTLM and RPA (--disable-NTLM --disable-RPA), so they will be gone from Fedora 46 onwards. I kept them enabled in the stable branches to avoid removing functionality mid-release, since the 6.6.7 buffer guard already addresses the issue there. Thanks for the heads-up. > Reproducible: Always > > Steps to Reproduce: > This is a source code vulnerability that would require a server to be > maliciously compromised. > Actual Results: > fetchmail can crash and a few dozen bytes can be injected on the stack > including the return address. > > Expected Results: > no vulnerability in NTLM authentication code (ntlm_helper(), in particular)
Hello, Thank you both for your work as maintainers. I have reserved CVE-2026-94184 under the Red Hat CNA as this also affects RHEL and other Red Hat products. Just a few questions: 1. Did MITRE provide a reason for their rejection? 2. Would you be able to provide a CVSSv3 vector and impact rating for this vulnerability? (https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator and https://access.redhat.com/security/updates/classification) I will work on making the CVE pages public in the coming days.
Hi Melissa, Mitre received the request in June through their new portal and did not respond in two months in spite of two reminders. I cannot tell why they ignored it. I erased the request before seeking RedHatCNA assistance. Will look into cvss later and follow up.
Melissa, Vitezslav, The CVSS is SOLELY dependent on what the compiler chosen for the binary package (i. e. what's in the .spec file and RPM macro defaults) does in terms of stack layout in the affected function, and if it has stack smashing protection added. I hope Vitezslav can help here and has an overview what compilers on Red Hat's and Fedora's affected systems do. The decisive factors are: 1. IF the compiler places the vulnerable array (it is one of several) on top of the stack by rearranging variables (it may do that, but does not have to), then there is potential for an attack smashing the stack frame by a few dozen bytes; 2. IF the binary build (for the RPM) adds robust stack smashing protection (instrumentation) via compiler flags. If that detects the stack smashing by an attacking NTLM server, WORST CASE and for CVSS publication: if the compiler rearranges stack variables that the affected overrun variable lies on top of the stack AND there is no mitigation by the compiler and libc run-time that detects this when returning from the faulty function ntlm_helper() in fetchmail 6.6.6 or older. Only in this case there is a remote code execution possibility. IF HOWEVER the compiler leaves the vulnerable variable in the middle, as written in the source code, there is no vulnerability in terms of any CVSS scores - in that situation, the authentication attempt to the attacking server fails and that's it, without any additional adverse consequences for the user, his system, or environment. A faulty or rogue server can arbitrarily refuse a login already, there's no expansion of risk or vulnerability. In that case, I would specify CVSS v3.1 as AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H/E:U/RL:O/RC:C - ultimately and in extremo this is a remote code injection vulnerability, but the environmental influence is by the compiler chosen to compile the binary package, if it has stack smashing protection in place, CVSS Base Score: 8.1 Impact Subscore: 5.9 Exploitability Subscore: 2.2 CVSS Temporal Score: 7.1 CVSS Environmental Score: 7.1 Modified Impact Subscore: 5.9 Overall CVSS Score: 7.1 I left the "Environmental" unfilled because I would click the same fields as for the same score. MEDIUM CASE: if there is stack smashing protection through additional (Red Hat or Fedora added) compiler flags that **terminates** the process when detecting a stack variable overrun, then I would judge the CVSS v3.1 as AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:N/E:U/RL:O/RC:C which leads to these scores: CVSS Base Score: 0 Impact Subscore: 0 Exploitability Subscore: 2.2211673 CVSS Temporal Score: 0.0 CVSS Environmental Score: NA Modified Impact Subscore: NA Overall CVSS Score: 0.0 NON-VULNERABLE CASE: iff there is stack smashing protection in place that works with shadow stacks and will return from the faulty function and continue execution, and/or if the compiler puts the array variables on the stack in reverse or forward order of their order in the source file, potential attacks are fully contained in an adjacent variable that is no longer used, and there is no additional risk or vulnerabilities and the exploitability score goes down even more, not changing the base/overall scores from 0.
Created attachment 2158407 [details] revised v1.2 of CVE-2026-94184 = fetchmail-SA-2026-01 security announcement
Note I have released fetchmail 6.6.8 which corrects the misleading and inaccurate NEWS and fetchmail-SA-2026-01 files (revised version attached) that did ship with fetchmail 6.6.7, and also updates the po/LINGUAS file so as to install the sr (Serbian/Cyrillic) translation (it was shipping but not installed in some earlier releases) and adds a new traditional Chinese (zh_TW) translation.
I checked the actually shipped binaries plus debuginfo for all affected Fedora and RHEL builds. Build flags, taken from DW_AT_producer so these are the flags really used, are the same everywhere: -O2 -fstack-protector-strong -fstack-clash-protection -fcf-protection=full -fPIE The stack protector is verifiably active inside ntlm_helper() itself (canary load plus __stack_chk_fail). In every one of these builds the compiler kept the declaration order of the four local arrays, lowest to highest address: request -> challenge -> response -> msgbuf[2048] -> other locals -> canary -> saved registers -> return address So msgbuf, not response, is at the top of the frame. An overrun past the end of response has to cross well over 2000 bytes (all of msgbuf plus a couple of hundred bytes of other locals) before it even reaches the canary, and more before the return address, whereas the overflow is a few dozen bytes. It is absorbed by msgbuf, which at that point has already been consumed apart from the flags value. This is identical for every affected package, and also on aarch64, ppc64le and s390x, which I checked additionally. So no shipped Fedora or RHEL binary is in the exploitable layout; the effect there is a corrupted NegotiateFlags and a failed authentication.
FEDORA-2026-8ffc03a2ce (fetchmail-6.6.8-1.fc45) has been submitted as an update to Fedora 45. https://bodhi.fedoraproject.org/updates/FEDORA-2026-8ffc03a2ce
FEDORA-2026-ffdc059b16 (fetchmail-6.6.8-1.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-ffdc059b16
FEDORA-2026-fdb231ab53 (fetchmail-6.6.8-1.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2026-fdb231ab53
Created attachment 2158483 [details] revised v1.3 of CVE-2026-94184 = fetchmail-SA-2026-01 security announcement (only Debian bug # corrected) re-uploaded corrected version of attachment with proper Debian Bug #.
FEDORA-2026-8ffc03a2ce has been pushed to the Fedora 45 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-8ffc03a2ce` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-8ffc03a2ce See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-ffdc059b16 has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-ffdc059b16` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-ffdc059b16 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-fdb231ab53 has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-fdb231ab53` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-fdb231ab53 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.