SSSD EUVD-2026-75084

The target system must be running SSSD with the IdP/OIDC authentication provider explicitly configured (id_provider = oidc or equivalent in sssd.conf) - this is not the default SSSD configuration, which uses ldap or ad. The attacker must hold a valid credential for an OIDC IdP account whose sub claim is a strict prefix (not equal to) the target account's sub claim, requiring prior knowledge of the target's exact identifier. Exploitation is further gated by the IdP's sub-claim naming policy: if the IdP enforces UUID-format or fixed-length identifiers, prefix collisions become structurally impossible. Standard SSSD deployments using LDAP, AD, or Kerberos providers are entirely unaffected, as the vulnerable code path is specific to the IdP provider. The CVSS PR:L metric confirms a valid IdP account is required - unauthenticated exploitation is not possible.

The CVSS 7.5 vector (AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H) is internally consistent and well-calibrated: AC:H reflects the genuine prerequisite that the attacker must possess an IdP-registered identity whose sub claim is a strict prefix of the target's, requiring both advance knowledge of the target's identifier and the ability to register a matching prefix account. PR:L correctly captures that the attacker must hold a valid IdP credential. The full C:H/I:H/A:H impact is appropriate because successful exploitation grants complete impersonation of the target, including shell access and file system permissions. No CISA KEV listing, no EPSS data, and no public PoC are present in the source data, keeping assessed real-world exploitation probability lower than the impact metrics alone suggest. The 'Information Disclosure' tag materially understates actual impact - this is a full authentication bypass enabling account takeover. Risk is highest in organizations using Red Hat SSO, Keycloak, or similar OIDC IdPs integrated with SSSD on RHEL or OpenShift nodes.

An attacker registers an IdP account with subject identifier ops in an environment where the target system administrator account has subject identifier ops_admin. The attacker authenticates to an RHEL server via OIDC; SSSD's eval_access_token_buf() calls strncmp('ops_admin', 'ops', 3), which returns 0, and SSSD grants the attacker a login session as the ops_admin user, including all associated group memberships and sudo rights. No public PoC has been identified, but the bug's mechanics are simple enough that discovery by an insider or IdP-tenant adversary is plausible.