CVE-2026-104031 in SSSD
Summary
by MITRE • 10/06/2026
A flaw was found in SSSD. In configurations where the autofs responder service is enabled, memory allocated during successful request processing is not released until the client connection terminates. A local attacker can exploit this vulnerability by maintaining an open connection and repeatedly submitting valid requests, leading to memory exhaustion and a Denial of Service (DoS).
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/06/2026
The System Security Services Daemon, commonly known as SSSD, serves as a critical component in Linux environments for managing identity and authentication. It provides access control policies and acts as an interface between the system and various identity sources such as LDAP servers or Active Directory domains. Within this architecture, the autofs responder plays a specific role by handling automount requests from clients seeking to mount network file systems dynamically. While essential for seamless resource accessibility in enterprise environments, the implementation of this service contains a significant memory management flaw that undermines its stability under sustained load conditions.
The core technical vulnerability lies in how SSSD handles memory allocation during the processing of autofs responder requests. When the daemon receives and successfully processes a valid request from a client, it allocates specific blocks of memory to manage the state and data associated with that transaction. However, due to an implementation error, these allocated memory segments are not properly freed or released back to the system after the operation completes. Instead, this memory remains reserved within the process space until the underlying TCP connection between the SSSD daemon and the client is explicitly closed by either party. This behavior creates a linear accumulation of unused memory allocations for every active session that interacts with the autofs responder service.
This architectural oversight leads directly to a severe Denial of Service condition when exploited by an attacker with local access privileges on the host system. A malicious actor can initiate multiple connections to the SSSD daemon and continuously submit valid automount requests without ever closing these sessions. Because each request consumes memory that is never reclaimed, the process gradually exhausts all available RAM allocated to it or potentially impacts overall system stability if swap space is also depleted. The result is a complete halt of service for legitimate users who rely on SSSD for authentication and file mounting capabilities, effectively rendering the affected systems unusable until the daemon crashes or is manually restarted by an administrator.
From a classification perspective, this vulnerability aligns with CWE-401, which describes missing release of memory after effective usage. It represents a classic resource leak pattern where resources are acquired but not returned to the pool upon completion of their intended function. In terms of offensive security frameworks such as MITRE ATT&CK, this flaw facilitates local privilege escalation through denial of service tactics, specifically falling under techniques that target system availability rather than confidentiality or integrity. An attacker leveraging this issue does not need elevated privileges initially, only standard user access to open sockets and send requests, making it a low-barrier vector for disrupting critical infrastructure services.
Mitigation strategies must address both the immediate operational risk and the underlying code defect. Administrators should monitor memory usage of SSSD processes on systems where the autofs responder is enabled, particularly in environments with high volumes of dynamic mount operations. Implementing connection timeouts or rate limiting at the network level can help prevent a single client from maintaining persistent connections indefinitely while submitting requests. Furthermore, applying vendor-provided patches that correct the memory deallocation logic within the SSSD source code is essential for long-term remediation until such updates are available in stable repositories. Until then, restricting local access to systems running vulnerable versions of SSSD reduces the attack surface significantly by limiting who can initiate the exploitative connections required to trigger this resource exhaustion flaw.