Why the version number does not answer the question
The upstream Exim fix carries the number 4.100.1: the Ubuntu entry for CVE-2026-94054 describes a flaw present in "Exim before 4.100.1". Yet Ubuntu 24.04 ships a package fixed in 4.97-4ubuntu4.8, and Ubuntu 22.04 one fixed in 4.95-4ubuntu2.12. Both are far below 4.100.1, and both are fixed.
The reason is mechanical. A distribution backports the fix into the older branch it maintains: the upstream number does not move, only the package revision, after the hyphen, changes. Comparing the output of exim4 -bV with 4.100.1 therefore raises a false alarm on a healthy server. The opposite exists too: an Exim compiled by hand, outside the package manager, has no distribution revision, and only its upstream number counts. The right question is not "is my version high enough?" but "does my package contain the fixed revision, and does its changelog cite the CVE?".
Fixed Exim packages by distribution (checked on 28 October 2026)
Scroll the table
| Distribution | Fixed exim4 package | Status recorded |
|---|---|---|
| Ubuntu 26.04 LTS | 4.99.1-1ubuntu1.5 | Fixed (USN-8834-1) |
| Ubuntu 24.04 LTS | 4.97-4ubuntu4.8 | Fixed (USN-8834-1) |
| Ubuntu 22.04 LTS | 4.95-4ubuntu2.12 | Fixed (USN-8834-1) |
| Ubuntu 26.10 | Not applicable | Not affected according to Ubuntu |
| Debian 13 (trixie), security repository | 4.98.2-1+deb13u5 | Fixed (DSA-6522-1) |
| Debian 12 (bookworm) | 4.96-15+deb12u10 | Marked vulnerable on 28 October 2026: re-read the tracker before acting |
| Debian forky and sid | 4.100.1-4 | Fixed |
| AlmaLinux, Rocky | Depends on the repository providing Exim | Read the package changelog |
What Ubuntu advisory USN-8834-1 fixes
- CVE-2026-94054 — out-of-bounds write when Proxy-Protocol is used with an attacker-controlled proxy. Ubuntu scores it 7.0 in CVSS 3, priority Medium.
- CVE-2026-94056 — uninitialized stack read in the same Proxy-Protocol context, with possible information disclosure.
- CVE-2026-94057 — SMTP smuggling: data sent after a rejection during the DATA command allows message injection. No proxy is needed.
- CVE-2026-94055 — use-after-free with GnuTLS and non-default TLS settings. Only Ubuntu 26.04 was affected.
- A priority is not your risk — the Medium priority judges the flaw in general. It does not tell whether your server accepts connections through a proxy: the tests below do.
Checking an Exim package, command by command
Read the raw version
exim4 -bVprints the upstream Exim version (the binary is calledeximon other systems). Note it, but conclude nothing: this is the number that cannot be compared with 4.100.1.Read the package revision
dpkg -s exim4-daemon-light | grep Versiongives the installed revision. Swap the name forexim4-daemon-heavyif that is your variant, and list them withdpkg -l 'exim4*'. Compare with the reference table.Look for the CVE in the changelog
apt changelog exim4 | grep -n CVE-2026-94054. A matching line means the fix is in the package. No line: run the update, then repeat the command.On AlmaLinux or Rocky
rpm -q --changelog exim | grep CVEdoes the same job, provided the package comes from a repository that publishes it. Same logic for Dovecot withrpm -q --changelog dovecot | grep CVE-2026-42006.Ask the distribution
On Debian,
debsecanlists the known CVEs for installed packages. On Ubuntu,ubuntu-security-statussummarizes which packages still receive security fixes; it does not target one CVE.Update
sudo apt update && sudo apt install --only-upgrade 'exim4*', then the same command with'dovecot*'if Dovecot runs on the machine.Check the loaded process
ls -l /proc/$(pgrep -o exim4)/exe. The mention (deleted) shows the binary was replaced on disk while the old one still runs in memory. Restart withsudo systemctl restart exim4.
Checking and fixing by environment
Scroll the table
| Environment | Check | Fix |
|---|---|---|
| Debian, Ubuntu | `dpkg -s exim4-daemon-light | grep Version` | `sudo apt update && sudo apt install --only-upgrade 'exim4*' 'dovecot*'` |
| AlmaLinux, Rocky (Dovecot) | `rpm -q --changelog dovecot | grep CVE-2026-42006` | `sudo dnf upgrade dovecot` |
| AlmaLinux, Rocky (Exim outside the base repositories) | `rpm -q --changelog exim | grep CVE-2026-94054` | Update through the repository that provides it, or wait for its fix |
| Docker (Exim or Dovecot image) | `docker exec <container> exim -bV` | `docker pull <image>` then recreate the container |
| Mailcow | `docker compose exec dovecot-mailcow dovecot --version` | `./update.sh` in the Mailcow folder |
| Compiled by hand | `exim -bV` | Recompile from a fixed upstream version, or switch to the distribution package |
Updating does not replace the running process
After the update, a daemon that is already running keeps executing the old binary. Restart with sudo systemctl restart exim4 and sudo systemctl restart dovecot, or let needrestart offer it. For Ubuntu 20.04 and earlier, the Ubuntu entry shows a "needs evaluation" status: without a fixed package, plan an OS migration rather than waiting.
Are you exposed: the Proxy-Protocol test
Two of the four CVEs require Proxy-Protocol. In Exim it is enabled by the main option hosts_proxy. Without it, no ordinary client reaches the code involved in CVE-2026-94054 and CVE-2026-94056. Test with exim4 -bP hosts_proxy.
An empty value means no host is declared as a proxy; an unknown-option message may come from a build without this support: check it in your build's documentation. A list of addresses means those hosts speak Proxy-Protocol: the risk then depends on how far you trust them, since the flaw assumes an attacker-controlled proxy. This test does not cover CVE-2026-94057, the SMTP smuggling, which applies without a proxy, nor CVE-2026-94055, tied to GnuTLS and non-default TLS settings on Ubuntu 26.04. For those, the update remains the only defense.
If your distribution has no fixed package yet
The table shows it: on 28 October 2026, Debian 12 was still marked vulnerable for Exim. Waiting with no action is not the only option. Start by reducing what is reachable: if exim4 -bP hosts_proxy returns an empty value, the two Proxy-Protocol flaws cannot be reached by an ordinary client, and you gain time on them. For the rest, limit the allowed sources on port 25 when your usage permits, and watch your distribution tracker until the package is published.
Rebuilding Exim from upstream sources is possible, but you then become the only maintainer of that binary: no apt upgrade will ever fix it again. Keep this choice for a team that accepts that follow-up. If the distribution is out of support, the lasting way out is a migration to a maintained version, to be planned rather than endured.
Dovecot: CVE-2026-42006 and sources that do not agree
CVE-2026-42006 describes unbounded memory use when an IMAP client sends excessive opening braces. It bypasses the fix for CVE-2026-27857; according to the Debian tracker, that fix only blocked closing braces. Dovecot.org published it on 12 May 2026 with a Moderate severity, but lists neither affected nor fixed versions: the site points to the Open-Xchange advisory.
Debian gives precise packages: 1:2.3.19.1+dfsg1-2.1+deb12u6 for bookworm and 1:2.4.1+dfsg1-6+deb13u7 for trixie in the security repository. The tracker lists another revision for trixie outside the security repository: when two revisions coexist, check the one your apt installs with apt-get changelog dovecot-core | grep CVE-2026-42006. Deduce nothing from dovecot --version alone. If the update has to wait, the documented mitigation is a low vsz_limit value for the imap process: it caps the memory a client can consume.
Two sources stay silent or disagree, and it is better to know it. Dovecot.org does not publish fixed versions, where Debian gives them per distribution. And the exim.org security page did not index these CVEs when we checked on 28 October 2026: we therefore cite no upstream date for Exim. The distribution advisories, Ubuntu and Debian, are what decide your package.
Checking the logs after the fix
Fixing does not tell whether someone came by earlier. Look for abnormal stops since the advisory: journalctl -u exim4 --since "2026-09-28" | grep -i -E 'segfault|signal|core dumped', then journalctl -k --since "2026-09-28" | grep -i -E 'segfault|out of memory'. On the Dovecot side, journalctl -u dovecot --since "2026-09-28" | grep -i -E 'out of memory|killed' spots an imap process killed for lack of memory.
Also read the Exim log (/var/log/exim4/mainlog on Debian and Ubuntu) for messages sent from senders you do not know. No trace proves nothing: a memory leak leaves no line. Keep these commands as a routine check after each advisory, not as proof of innocence.
Who keeps a mail server patched?
Fixing an exposed MTA seems reserved for a system administrator. The procedure above takes a few commands and replays on every advisory: read the changelog, update, restart, check the process. The real cost is vigilance, meaning following the USN and DSA notices, testing, and never leaving a machine aside.
On a ServOrbit VPS you get root access and a choice of OS (Ubuntu, Debian, AlmaLinux, Rocky). If you do not want to keep these fixes up yourself, the VPS administration option exists, to be subscribed separately. This guide is provided as is, without support for your configuration. And if your goal is only to have professional addresses, professional email spares you from running an MTA.
Official documentation
Ubuntu notice USN-8834-1 (Exim): https://ubuntu.com/security/notices/USN-8834-1
Ubuntu entry for CVE-2026-94054: https://ubuntu.com/security/CVE-2026-94054
Debian tracker for CVE-2026-94054: https://security-tracker.debian.org/tracker/CVE-2026-94054
Debian tracker for CVE-2026-42006: https://security-tracker.debian.org/tracker/CVE-2026-42006
Dovecot security page: https://dovecot.org/security
Open-Xchange advisory oxdc-adv-2026-0002: https://documentation.open-xchange.com/dovecot/security/advisories/html/2026/oxdc-adv-2026-0002.html
Exim proxy support (hosts_proxy): https://www.exim.org/exim-html-current/doc/html/spec_html/ch-proxies.html
Exim security page: https://www.exim.org/static/doc/security/
