SSSD CVE-2026-104031

Exploitation requires the SSSD autofs responder service to be explicitly enabled (i.e., 'autofs' present in the services list of sssd.conf) - this is a non-default configuration condition without which the vulnerable code path is not reachable. The attacker must additionally have local access with an authenticated unprivileged account (PR:L) capable of opening a client connection to the responder, and must sustain that open connection while repeatedly issuing valid requests, since memory is only reclaimed on connection termination. Limiting factors: no remote vector (AV:L), no impact to confidentiality or integrity, and the requirement for a shared/multi-user host for the DoS to affect other principals meaningfully.

This is a genuine but moderate-priority issue, correctly rated medium (CVSS 5.5). The CVSS vector CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H is internally consistent with the description: local access (AV:L), low attack complexity (AC:L), and low privileges (PR:L) are all satisfied by any local user able to open a client connection to the SSSD autofs responder socket, with impact confined to availability (A:H) and no confidentiality or integrity effect (C:N/I:N) - consistent with a memory-leak-driven DoS (CWE-772). No EPSS score, KEV listing, or public exploit was provided in the input, so there is no signal of active or probable exploitation; absence of these should not be read as proof of safety, only as no evidence of weaponization. The realistic risk is a local denial of service (memory exhaustion affecting the SSSD process and potentially the host), not remote compromise or data exposure. This is a reliability/availability hardening fix rather than an urgent emergency patch: priority rises only in multi-tenant hosts where untrusted local users exist AND the autofs responder is explicitly enabled, which is a non-default precondition that materially limits real-world exposure.

On a system where the SSSD autofs responder is enabled, a logged-in local user (e.g., a shell user on a shared RHEL host) opens a connection to the responder and keeps it open while repeatedly submitting valid autofs lookup requests. Because memory from each successful request is not freed until the connection closes, sustained request flooding exhausts memory and denies the service to legitimate users. No public exploit was identified at time of analysis, but the technique requires no special tooling.