CVE-2026-104032

A flaw was found in SSSD. An unprivileged local user can repeatedly request master automount map updates through the autofs responder due to missing authorization checks. This triggers global cache invalidation and forces repeated lookups to backend directory providers, leading to a Denial of Service (DoS) from degraded automount availability and elevated resource consumption.

Red Hat rates this vulnerability as Moderate severity because it is restricted to local denial of service without compromising system confidentiality or integrity. The issue only presents a risk on systems configured with the SSSD automount responder where untrusted local users have access to the responder socket. Under these conditions, an authenticated local attacker can degrade automount lookup performance and increase load on backend directory services by triggering frequent cache purges, but cannot gain elevated privileges.

The CVSS score(s) listed for this vulnerability do not reflect the associated product's status, and are included for informational purposes to better understand the severity of this vulnerability.

If SSSD automount integration is not required, disable the SSSD autofs responder so that unprivileged local users cannot issue autofs requests against it:

systemctl --now mask sssd-autofs.socket sssd-autofs.service

If the autofs responder is enabled through the services line in the [sssd] section of /etc/sssd/sssd.conf, remove autofs from that line and restart SSSD with systemctl restart sssd.

Caveats: disabling the autofs responder means SSSD will no longer serve automount maps to the automount daemon, and restarting SSSD briefly interrupts active identity lookups and automount operations. Where disabling the responder is not possible, restricting access to the autofs responder socket (for example via socket permissions or limiting which local UIDs may connect) so that only the intended trusted clients can reach it also reduces exposure before a fix is available.