2.4.2 breaks user iterations for LDAP
Hello everyone,
Due to the fix for CVE-2025-30189, routines like userdb_ldap_preinit() call auth_cache_parse_key_and_fields() unconditionally, with the eventually called auth_cache_parse_key_exclude() erroring if a cache key could not be constructed.
It’s also noteworthy that this call happens regardless of whether use_cache is set or not, and as of such failing to construct a cache key would cause an error even if use_cache = no was set for that database.
This is however an issue for user iteration with LDAP, as documented here LDAP | Dovecot CE <https://doc.dovecot.org/2.4.2/core/config/auth/databases/ldap.html#user-iteration> . Such a userdb only has iterate_filter fields that would inherently not be containing any user variables.
The call to auth_cache_parse_key_and_fields() uses a combination of ldap_base and userdb_ldap_filter anyway (so whatever is in iterate_filter isn’t considered), and for an iteration userdb as described in the documentation, the latter would be empty.
Alas, I ended up getting the rather confusing error
- auth: Fatal: auth-cache: dc=rev-crew,dc=info: Cache key must contain at least one variable
With dc=rev-crew,dc=info being my ldap_base setting for the iteration userdb. I’m not critically dependent on the user iteration, so I’ve commented the userdb out for now, but this would need fixing.
Regards,
Christian Pfeiffer
Hello everyone,
Due to the fix for CVE-2025-30189, routines like userdb_ldap_preinit() call auth_cache_parse_key_and_fields() unconditionally, with the eventually called auth_cache_parse_key_exclude() erroring if a cache key could not be constructed.
It's also noteworthy that this call happens regardless of whether use_cache is set or not, and as of such failing to construct a cache key would cause an error even if use_cache = no was set for that database.
This is however an issue for user iteration with LDAP, as documented here [1]LDAP | Dovecot CE. Such a userdb only has iterate_filter fields that would inherently not be containing any user variables.
The call to auth_cache_parse_key_and_fields() uses a combination of ldap_base and userdb_ldap_filter anyway (so whatever is in iterate_filter isn't considered), and for an iteration userdb as described in the documentation, the latter would be empty.
Alas, I ended up getting the rather confusing error
o auth: Fatal: auth-cache: dc=rev-crew,dc=info: Cache key must contain
at least one variableWith dc=rev-crew,dc=info being my ldap_base setting for the iteration userdb. I'm not critically dependent on the user iteration, so I've commented the userdb out for now, but this would need fixing.
Regards,
Christian Pfeiffer
References
Visible links
On 6. Nov 2025, at 2.52, cpfeiffer--- via dovecot <dovecot@dovecot.org> wrote:
Hello everyone,
Due to the fix for CVE-2025-30189, routines like userdb_ldap_preinit() call auth_cache_parse_key_and_fields() unconditionally, with the eventually called auth_cache_parse_key_exclude() erroring if a cache key could not be constructed.
It's also noteworthy that this call happens regardless of whether use_cache is set or not, and as of such failing to construct a cache key would cause an error even if use_cache = no was set for that database.
This is however an issue for user iteration with LDAP, as documented here [1]LDAP | Dovecot CE. Such a userdb only has iterate_filter fields that would inherently not be containing any user variables.
Do you have a separate userdb now for ldap userdb lookups? That was the intention at least that usually the userdb filter and iteration would be in the same userdb, not separate ones. Anyway, I'll try to figure out a fix.
I guess that's not saying it very clearly.
Yes, I do. The relevant part of my config is:
ldap_uris = ldaps://ldap.rev-crew.info ldap_auth_dn = cn=dovecot,ou=Services,dc=rev-crew,dc=info ldap_auth_dn_password = ... ldap_base = dc=rev-crew,dc=info
passdb ldap { driver = ldap ldap_filter = (&(objectClass=mailRecipient)(mailRoutingAddress=%{user})) passdb_ldap_bind = yes fields { user=%{ldap:mailRoutingAddress} } }
userdb static { fields { uid=vmail gid=vmail home=/var/mail/vmail/%{user | domain}/%{user | username} } }
#userdb ldap {
driver = ldap
iterate_filter = (objectClass=mailRecipient)
passdb_ldap_bind = yes
iterate_fields {
user=%{ldap:mailRoutingAddress}
}
#}
The second, commented out userdb is just for iterating users, just like in the documentation. In my use case, I don't need need to dynamically look up attributes from the user, so I'm using a static userdb for that, but to be able to iterate users, that second userdb would be needed. I've commented it out for the moment to keep things running.
-----Original Message----- From: Timo Sirainen <timo@sirainen.com> Sent: 06 November 2025 10:52 To: cpfeiffer@rev-crew.info Cc: dovecot@dovecot.org Subject: Re: 2.4.2 breaks user iterations for LDAP
On 6. Nov 2025, at 2.52, cpfeiffer--- via dovecot <dovecot@dovecot.org> wrote:
Hello everyone,
Due to the fix for CVE-2025-30189, routines like userdb_ldap_preinit() call auth_cache_parse_key_and_fields() unconditionally, with the eventually called auth_cache_parse_key_exclude() erroring if a cache key could not be constructed.
It's also noteworthy that this call happens regardless of whether use_cache is set or not, and as of such failing to construct a cache key would cause an error even if use_cache = no was set for that database.
This is however an issue for user iteration with LDAP, as documented here [1]LDAP | Dovecot CE. Such a userdb only has iterate_filter fields that would inherently not be containing any user variables.
Do you have a separate userdb now for ldap userdb lookups? That was the intention at least that usually the userdb filter and iteration would be in the same userdb, not separate ones. Anyway, I'll try to figure out a fix.
I guess that's not saying it very clearly.
Has this been addressed? I also experience this issue.
I am also unable to use user binds for password authentication; I must use ldap_auth_dn with a service account before it works. Attempting to use passdb_ldap_bind will fail with the same error otherwise.
For example, this doesn't work:
ldap_uris = ldapi://abc ldap_base = ou=dudes,dc=mysite passdb ldap { ldap_connection_group = login bind = yes bind_userdn = uid=%{user | username | lower },ou=dudes,dc=mysite }
Adding ldap_auth_dn allows it to continue.
On 18/02/2026 23:36 EET sev monster via dovecot <dovecot@dovecot.org> wrote:
Has this been addressed? I also experience this issue.
I am also unable to use user binds for password authentication; I must use ldap_auth_dn with a service account before it works. Attempting to use passdb_ldap_bind will fail with the same error otherwise.
For example, this doesn't work:
ldap_uris = ldapi://abc ldap_base = ou=dudes,dc=mysite passdb ldap { ldap_connection_group = login bind = yes bind_userdn = uid=%{user | username | lower },ou=dudes,dc=mysite }
Adding
ldap_auth_dnallows it to continue.
Again, the error you get would've been useful. But it's very likely fixed with
https://github.com/dovecot/core/compare/d4ca5ddf4030f9e2d391881b6ca5968b4504...
Aki
Feb 19, 2026 12:11:57 Aki Tuomi via dovecot <dovecot@dovecot.org>:
Again, the error you get would've been useful. But it's very likely fixed with
https://github.com/dovecot/core/compare/d4ca5ddf4030f9e2d391881b6ca5968b4504...
The error I got was exactly the same as what has already been reported, as mentioned. Not sure how that would be helpful, but I'll try to remember for next time.
Great to hear that it's hopefilly fixed. If I have time I'll build with that patch and see if it works.
Regards.
Feb 19, 2026 12:11:57 Aki Tuomi via dovecot <dovecot@dovecot.org>:
Again, the error you get would've been useful. But it's very likely fixed with
https://github.com/dovecot/core/compare/d4ca5ddf4030f9e2d391881b6ca5968b4504...
The error I got was exactly the same as what has already been reported, as mentioned. Not sure how that would be helpful, but I'll try to remember for next time.
Great to hear that it's hopefilly fixed. If I have time I'll build with that patch and see if it works.
Regards.
participants (4)
-
Aki Tuomi
-
cpfeiffer＠rev-crew.info
-
sev monster
-
Timo Sirainen