| ▲ | Dead.Letter (CVE-2026-45185) – How XBOW found an unauthenticated RCE on Exim(xbow.com) |
| 42 points by fedek_ 3 hours ago | 14 comments |
| |
|
| ▲ | ofjcihen 2 hours ago | parent | next [-] |
| >What follows is, before anything else, a story. One of those old, well-worn ones. Gag. |
|
| ▲ | fulafel an hour ago | parent | prev | next [-] |
| Previously (2023): https://www.bleepingcomputer.com/news/security/millions-of-e... Previously (2020): https://www.exim.org/static/doc/security/CVE-2020-qualys/CVE... Previously (2019): https://www.cvedetails.com/vulnerability-list/vendor_id-1091... |
|
| ▲ | kro 2 hours ago | parent | prev | next [-] |
| It says coordinated distro release today, and I've received a notice earlier today but that does not include the CVE number. That's confusing / does not seem very coordinated to release 2 separate security update notices in a day. https://lists.debian.org/debian-security-announce/2026/msg00... |
|
| ▲ | aftbit 3 hours ago | parent | prev | next [-] |
| Ok now do postfix |
| |
| ▲ | sys42590 2 hours ago | parent | next [-] | | Many years ago I used Exim because it was default for my distro of choice back then. But after a few emergency patchings caused by yet another RCE in Exim I learned that switching to Postfix massively improved my sleep quality. | | |
| ▲ | tptacek 2 hours ago | parent [-] | | There's a weird folk belief that Exim is a secure 2nd-generation MTA, but it's not; it's a 1st generation MTA, like Sendmail and Smail. The two "secure" 2nd generation MTAs are Postfix and qmail. You shouldn't use those either, really; there is no reason to run a memory-unsafe MTA, or, for that matter, an MTA that isn't backed by a real database. | | |
| ▲ | loloquwowndueo an hour ago | parent [-] | | Which one would you suggest using? I’ve been looking at Stalwart to replace my old exim setup, wondering if it’s a reasonable choice. | | |
| ▲ | tptacek an hour ago | parent [-] | | If security is your concern, Stalwart seems like a fine option, almost certainly better than Postfix. |
|
|
| |
| ▲ | kees99 2 hours ago | parent | prev [-] | | Nah, go straight for qmail. Give it your best try. | | |
| ▲ | rs_rs_rs_rs_rs 2 hours ago | parent [-] | | The usable qmail got owned by AI already, the unusable one not yet! | | |
| ▲ | tptacek 2 hours ago | parent [-] | | Not by AI, but by humans awhile ago. I think Qualys weaponized a wontfix LP64 integer overflow in it just a couple years ago? | | |
| ▲ | rs_rs_rs_rs_rs 2 hours ago | parent [-] | | The Calif people found a nice bug in a qmail fork(what I consider usable qmail) some weeks ago. | | |
| ▲ | tptacek an hour ago | parent [-] | | Right, and that fork is the only version of qmail people still run, and the bug they found was extremely funny given Bernstein's original qmail design (it was, if I remember right, a popen(3) vulnerability --- something that never would have showed up in Bernstein's code, but that's what happens when code gets abandoned, it gets picked up by people who don't really understand it). But it's hard to charge that vulnerability against the original qmail design. (I don't think anyone should run qmail.) |
|
|
|
|
|
|
| ▲ | stackghost 2 hours ago | parent | prev [-] |
| >The bug is a use-after-free triggered when a TLS connection is handled by GnuTLS Color me surprised. The GNU ecosystem has had more than its fair share of CVEs over the years to the point that it's now a common trope: https://soatok.blog/2020/07/08/gnu-a-heuristic-for-bad-crypt... |
