SSSD EUVD-2026-52258

Exploitation requires a valid local user account on the target system with access to the SSSD NSS responder socket (default path /var/lib/sss/pipes/nss), which is readable and writable by unprivileged users by design on affected RHEL systems. The vulnerable code path is triggered exclusively through GETHOSTBYADDR (reverse address lookup) requests to the NSS responder; other SSSD responders such as PAM or autofs are not implicated. No group membership, SUID binary, or elevated privilege is required - a standard shell account suffices. Exploitation is strictly local (AV:L); an attacker without an existing local account cannot reach the socket remotely. What limits real-world exploitation: the attacker must already have local access, the impact is limited to DoS (no code execution or data exfiltration is established), and SSSD will recover upon daemon restart. The vulnerability does not require any non-default SSSD configuration - any RHEL system with SSSD enabled and NSS integration active is susceptible.

The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) accurately characterizes the threat profile: exploitation is constrained to local access with standard user privileges, with no special attack complexity. The high availability impact (A:H) is meaningful - crashing the SSSD NSS responder disrupts authentication and name resolution for the entire system, not just the attacking user's session, making this a credible insider threat or post-compromise denial-of-service primitive. The source data includes an 'Information Disclosure' tag, which conflicts with the C:N CVSS metric; while out-of-bounds reads can theoretically leak adjacent memory contents, the description text establishes only process crash as the documented outcome - this discrepancy should be verified against the Red Hat advisory. No EPSS score was provided, and the absence of KEV listing and public exploit code keeps real-world risk moderate. In multi-tenant environments (shared servers, HPC clusters, container hosts) where SSSD mediates authentication for many users, the denial-of-service impact is amplified significantly. Single-user workstations represent lower practical risk.

A local user on an affected RHEL server constructs a malformed GETHOSTBYADDR packet with an addrlen value larger than the remaining packet body and writes it to the SSSD NSS responder socket, which is world-accessible by default. The sss_nss_protocol_parse_addr() function reads past the end of the allocated buffer, triggering an out-of-bounds read that crashes the SSSD NSS responder process. With SSSD down, all users relying on it for authentication and name resolution - including SSH sessions and sudo - are denied service until an administrator restarts the daemon.