SSSD EUVD-2026-84537

Requires SSSD configured with the LDAP access provider AND ldap_access_order containing 'ppolicy' or 'lockout' - this is not the default access-control path and must be explicitly set. The fail-open only triggers when a user lookup returns zero results (i.e., the account has been deleted or deprovisioned in the directory). The attacker must possess prior valid account context on the SSSD-managed host (PR:L); there is no path for a never-authorized external attacker. This is fundamentally an offboarding/deprovisioning-integrity flaw, which sharply limits the exploit population to formerly-legitimate users on hosts using the specific ppolicy/lockout access configuration.

The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N = 5.4 Medium) describes a network-reachable flaw requiring low privileges - specifically, the attacker must already hold a valid account context that is subsequently deprovisioned. This is not a mass-exploitable primitive: no EPSS score, KEV listing, or public PoC was supplied, so exploitation status is 'no public exploit identified at time of analysis.' The core issue is a fail-open access-control defect (CWE-280, improper handling of insufficient privileges), not a memory-corruption or RCE bug, and impact is bounded to C:L/I:L with no availability impact. The realistic risk is a specific insider/offboarding-integrity problem: a deleted or deprovisioned user retaining cached authorization rather than an external unauthenticated breach. This is a genuine but moderate-priority hygiene/deprovisioning risk, aligned with its Medium rating - not a high-CVSS-but-overstated issue, but also not urgent absent evidence of exploitation. Key missing signals: no fix version, EPSS, KEV, or PoC data is provided in the input, so patch-availability and exploitation likelihood cannot be independently confirmed.

A user with a previously valid account authenticates against an SSSD-backed host configured with the LDAP access provider and ldap_access_order including ppolicy or lockout. After the account is deleted or deprovisioned in the directory, the user lookup returns zero results, triggering the fail-open ppolicy check that returns success and caches an allow decision - so the former user continues to authenticate and access resources. No public exploit code was identified; exploitation requires the specific configuration and prior account context rather than a crafted payload.