Safe upgrade path from 2.4.1 to 2.4.4 (CVE-2026-40020) on Debian 13
Hello,
(Redirected here from support@dovecot.org - I understand that address is for commercial/Pro support, and this is a Community Edition question.)
We run a production mail server on Debian GNU/Linux 13 (trixie), using the Dovecot package currently shipped in the Debian 13 stable repository:
dovecot-core 1:2.4.1+dfsg1-6+deb13u6
We are affected by CVE-2026-40020 ("IMAP folders can be shared-spammed to everyone"), which as far as we understand is fixed upstream in Dovecot 2.4.4. Debian 13 stable does not yet ship a backported fix, so we are currently working around the issue by not using shared/ACL mailbox access at all, and waiting for an official Debian security update.
We would appreciate the community's guidance on a few points:
Is a safe, supported upgrade path from 2.4.1 to 2.4.4 recommended for a production instance currently installed from Debian's own package (rather than compiling from source or using a third-party repository)?
Are there any breaking changes between 2.4.1 and 2.4.4 we should be aware of - configuration syntax, Maildir index file format compatibility, or anything that would require downtime or re-indexing on a live mail store?
Our setup uses SQL-based virtual users/passdb (via PostfixAdmin/MySQL), Sieve filtering, and per-user quotas. Are there any known interactions between these features and the 2.4.4 update that we should test for before rolling it out?
Do you have a general recommendation on whether to wait for the Debian security team to backport the fix into 13 stable, versus updating manually ahead of that?
Any guidance, or a pointer to relevant release notes/changelog entries between 2.4.1 and 2.4.4, would be very helpful.
Thank you, Artem Ignatov IT Administrator, GK INVEST
Hi Artem Ignatov,
On 2026.08.21 12:06, Artem Ignatov via dovecot wrote:
Hello,
(Redirected here from support@dovecot.org - I understand that address is for commercial/Pro support, and this is a Community Edition question.)
We run a production mail server on Debian GNU/Linux 13 (trixie), using the Dovecot package currently shipped in the Debian 13 stable repository:
dovecot-core 1:2.4.1+dfsg1-6+deb13u6
We are affected by CVE-2026-40020 ("IMAP folders can be shared-spammed to everyone"), which as far as we understand is fixed upstream in Dovecot 2.4.4. Debian 13 stable does not yet ship a backported fix, so we are currently working around the issue by not using shared/ACL mailbox access at all, and waiting for an official Debian security update.
https://security-tracker.debian.org/tracker/CVE-2026-40020 According to Debian's Security database, it says trixie (security) 1:2.4.1+dfsg1-6+deb13u6 has this fixed
I appreciate Debian Security pages directly linking the exact commits. Browse to https://packages.debian.org/trixie/dovecot-core (right side pane it has a link for the original source and the Debian additions) and download: http://deb.debian.org/debian/pool/main/d/dovecot/dovecot_2.4.1+dfsg1-6+deb13... You can inspect the Debian specific package contents, especially the directory: debian/patches, where there are exact patches for the CVE and included in debian/patches/series. So applied during package creation. Actually it is a three piece patch set as it is listed among the referenced commits on the bottom of their CVE page.
So if you are using dovecot-core (1:2.4.1+dfsg1-6+deb13u6), consider this CVE fixed for your version. If you are still able to trigger the bug, despite of the above mentioned references, you should file a bug report.
I'm currently not primarily a Debian user (it was the first distro I used for several years before 2002), but often rely on their information and sometimes use patches to fix security issues outside of the Debian ecosystem. Although rarely there are some mishaps, but it is reliable.
BR: Dw.
We would appreciate the community's guidance on a few points:
Is a safe, supported upgrade path from 2.4.1 to 2.4.4 recommended for a production instance currently installed from Debian's own package (rather than compiling from source or using a third-party repository)?
Are there any breaking changes between 2.4.1 and 2.4.4 we should be aware of - configuration syntax, Maildir index file format compatibility, or anything that would require downtime or re-indexing on a live mail store?
Our setup uses SQL-based virtual users/passdb (via PostfixAdmin/MySQL), Sieve filtering, and per-user quotas. Are there any known interactions between these features and the 2.4.4 update that we should test for before rolling it out?
Do you have a general recommendation on whether to wait for the Debian security team to backport the fix into 13 stable, versus updating manually ahead of that?
Any guidance, or a pointer to relevant release notes/changelog entries between 2.4.1 and 2.4.4, would be very helpful.
Thank you, Artem Ignatov IT Administrator, GK INVEST
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
-- dr Tóth Attila, Radiológus, 06-20-825-8057 Attila Toth MD, Radiologist, +36-20-825-8057
Hi Attila, hi all,
Thank you for the pointer to the Debian security tracker - confirmed independently: trixie (security) dovecot-core 1:2.4.1+dfsg1-6+deb13u6 is listed as fixed for CVE-2026-40020 (DSA-6313-1), and that is exactly the version we have installed. Good to know we don't need to touch the packaging for that.
However, this raises a separate question. We had a long-standing, unrelated problem we suspected might share the same root cause: legitimate ACL-based mailbox sharing (granting a user read access to another user's mailbox via "doveadm acl set ... lookup read") does not work for us - the shared mailbox simply never appears for the grantee, neither through "doveadm mailbox list" nor through a real IMAP LIST command.
We just re-tested this live, now that the CVE fix is confirmed present:
- "doveadm acl set -u owner@domain INBOX user=grantee@domain lookup read" succeeds, and "doveadm acl get" confirms the right is stored correctly.
- "doveadm acl recalc" run for both the owner and the grantee.
- "doveadm mailbox list -u grantee@domain" (with and without an explicit "Shared*" pattern) shows only the grantee's own private folders - no Shared.<owner>.* namespace mailbox at all.
- A raw IMAP LIST via Python's imaplib as the grantee, after logging in normally, confirms the same: no shared mailbox listed.
Setup details:
- Dovecot 2.4.1 (Debian 13/trixie package, 1:2.4.1+dfsg1-6+deb13u6)
- Virtual users via SQL passdb/userdb (PostfixAdmin/MySQL), Maildir storage
- Shared namespace: prefix = Shared.%{owner_user | username}.
- acl plugin enabled, acl_shared_dict configured, dict entries do get populated correctly (checked directly against the dict backend)
So this looks like it's not (or not only) CVE-2026-40020 - something else seems to be preventing the shared namespace from actually surfacing the mailbox to the grantee, even with a correctly stored ACL right. Has anyone seen this specific symptom before, or is there a known additional step needed for SQL-based virtual users?
Happy to share the exact doveconf -n output for the relevant sections if useful.
Thank you, Artem Ignatov IT Administrator, GK INVEST
Hi!
When upgrading from 2.4.1 to 2.4.4 there are no stops required. Remember to change config_version after upgrade to get new defaults.
You can find latest packages from [1]https://repo.dovecot.org
Aki
On 21/08/2026 22:29 EEST Artem Ignatov via dovecot
<[2]dovecot@dovecot.org> wrote:
Hi Attila, hi all,
Thank you for the pointer to the Debian security tracker - confirmed
independently: trixie (security) dovecot-core 1:2.4.1+dfsg1-6+deb13u6 is
listed as fixed for CVE-2026-40020 (DSA-6313-1), and that is exactly the
version we have installed. Good to know we don't need to touch the
packaging for that.
However, this raises a separate question. We had a long-standing,
unrelated problem we suspected might share the same root cause:
legitimate ACL-based mailbox sharing (granting a user read access to
another user's mailbox via "doveadm acl set ... lookup read") does not
work for us - the shared mailbox simply never appears for the grantee,
neither through "doveadm mailbox list" nor through a real IMAP LIST
command.
We just re-tested this live, now that the CVE fix is confirmed present:
- "doveadm acl set -u owner@domain INBOX user=grantee@domain lookup
read"
succeeds, and "doveadm acl get" confirms the right is stored correctly.
- "doveadm acl recalc" run for both the owner and the grantee.
- "doveadm mailbox list -u grantee@domain" (with and without an explicit
"Shared*" pattern) shows only the grantee's own private folders - no
Shared.<owner>.* namespace mailbox at all.
- A raw IMAP LIST via Python's imaplib as the grantee, after logging in
normally, confirms the same: no shared mailbox listed.
Setup details:
- Dovecot 2.4.1 (Debian 13/trixie package, 1:2.4.1+dfsg1-6+deb13u6)
- Virtual users via SQL passdb/userdb (PostfixAdmin/MySQL), Maildir
storage
- Shared namespace: prefix = Shared.%{owner_user | username}.
- acl plugin enabled, acl_shared_dict configured, dict entries do get
populated correctly (checked directly against the dict backend)
So this looks like it's not (or not only) CVE-2026-40020 - something
else
seems to be preventing the shared namespace from actually surfacing the
mailbox to the grantee, even with a correctly stored ACL right. Has
anyone seen this specific symptom before, or is there a known additional
step needed for SQL-based virtual users?
Happy to share the exact doveconf -n output for the relevant sections if
useful.
Thank you,
Artem Ignatov
IT Administrator, GK INVEST
_______________________________________________
dovecot mailing list -- [3]dovecot@dovecot.org
To unsubscribe send an email to [4]dovecot-leave@dovecot.orgReferences
Visible links
- https://repo.dovecot.org/
- mailto:dovecot@dovecot.org
- mailto:dovecot@dovecot.org
- mailto:dovecot-leave@dovecot.org
participants (3)
-
Aki Tuomi
-
Artem Ignatov
-
Tóth Attila