CVE-2026-92821: Sssd: sssd: access control bypass via premature ldap access rule evaluation

AIONLYREPORT package: sssd-2.12.0-1.el10 ------ Summary: LDAP Access Control Bypass When pwdexpirepolicywarn Precedes Restrictive Rules in ldapaccessorder: an expired-password warning is converted into a successful PAM result before later LDAP access rules run, allowing configured filter, host, or similar restrictive checks to be bypassed. Requirements to exploit: A valid LDAP-backed account whose password is expired, an LDAP deployment using accessprovider = ldap with a compatible password-expiration policy, ldapaccessorder placing pwdexpirepolicywarn before restrictive rules, and a non-password authentication path such as SSH public key that still invokes SSSD account/access checks. Component affected: sssd-2.12.0-1.el10, LDAP access-control evaluation in src/providers/ldap/sdapaccess.c (sdapaccesschecknextrule()) and success mapping in src/providers/ldap/ldapaccess.c (sdappamaccesshandlerdone()). Version affected: sssd-2.12.0-1.el10 in LDAP deployments where ldapaccessorder places pwdexpirepolicywarn before restrictive rules. Patch available: no released package fix established; proposed patch included below Version fixed: unknown Upstream coordination: Not notified. CVSS: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N - 6.8 (MEDIUM) AV:N - reachable over the network through services that rely on SSSD LDAP account/access checks, such as SSH. AC:H - exploitation depends on a specific non-default rule ordering, an expired-password state, and a compatible non-password authentication path. PR:L - the attacker needs a valid account that can authenticate to the target service. UI:N - no separate victim interaction is required once the attacker initiates authentication. S:U - the impact remains within the vulnerable service's own security scope. C:H - a successful bypass can expose data on systems or services that should have remained inaccessible under filter, host, or rhost restrictions. I:H - the same bypass can permit unauthorized actions within those protected systems or services. A:N - the flaw does not inherently reduce availability. Impact: Moderate. This is a real authorization bypass with meaningful confidentiality and integrity consequences where LDAP access rules are used as security boundaries, but exploitation requires a valid account, an expired-password condition, and a specific non-default ldapaccessorder configuration. That fits a security flaw that can compromise resources under certain circumstances, while being less easily exploitable than a default-path or broadly reachable access-control failure. Embargo: no Reason: the issue is configuration-dependent, requires an already valid account, and can be mitigated immediately by reordering or removing pwdexpirepolicywarn from the front of ldapaccessorder. Acknowledgement: Aisle Research Vulnerability Details: The documented purpose of pwdexpirepolicywarn is to warn while still allowing login. The issue here is narrower: in the LDAP access path, that warning state terminates ordered rule evaluation before later restrictive checks are reached. In sdapaccesschecknextrule(), rule processing only continues while ret == EOK; when LDAPACCESSEXPIREPOLICYWARN converts an expired password into ERRPASSWORDEXPIREDWARN, the loop stops and returns that non-EOK status. c while (ret == EOK) { ... case LDAPACCESSEXPIREPOLICYWARN: ret = performpwexpirepolicy(state, state->domain, state->pd, state->accessctx->type, state->accessctx->idctx->opts); if (ret == ERRPASSWORDEXPIRED) { ret = ERRPASSWORDEXPIREDWARN; } break; ... } state->currentrule++; } return ret; That returned status is then treated as success in sdappamaccesshandlerdone(), which maps both EOK and ERRPASSWORDEXPIREDWARN to PAMSUCCESS. In deployments using an ordered configuration such as pwdexpirepolicywarn,filter,host, later filter, host, or rhost checks are skipped entirely, so an expired-password user can be accepted by the warning path before the restrictive rules run. Steps to reproduce: 1. Configure an LDAP-backed SSSD domain with accessprovider = ldap, ldappwdpolicy = shadow (or mitkerberos), ldapaccessorder = pwdexpirepolicywarn,filter,host, and a restrictive ldapaccessfilter or host rule that should deny the test user. 2. Ensure the test user's password is marked expired in the LDAP attributes used by the selected password policy. 3. Authenticate through a non-password method that still invokes account/access checks, such as SSH public key login. 4. Expected result: a later filter or host rule denies access. Actual result: the warning path returns ERRPASSWORDEXPIREDWARN, the handler maps it to PAMSUCCESS, and the later restrictive rules are not evaluated. Mitigation: Until a fix is available, do not place pwdexpirepolicywarn before restrictive entries in ldapaccessorder. If warning behavior is still required, place it after filter, host, rhost, or other denial-capable rules, or use pwdexpirepolicyreject where expired accounts should not continue through the access chain. Proposed Fix: Record the warning state, continue evaluating the remaining ordered rules, and only return ERRPASSWORDEXPIREDWARN after all configured access rules have passed. diff diff --git a/src/providers/ldap/sdapaccess.c b/src/providers/ldap/sdapaccess.c — a/src/providers/ldap/sdapaccess.c +++ b/src/providers/ldap/sdapaccess.c @@ struct sdapaccessreqctx { @@ sizet currentrule; enum sdapaccesscontroltype actype; + bool pwexpirewarnseen; }; @@ state->conn = conn; state->currentrule = 0; + state->pwexpirewarnseen = false; @@ static errnot sdapaccesschecknextrule(struct sdapaccessreqctx state, case LDAPACCESSEMPTY: / we are done with no errors /

return EOK; + / all rules passed; preserve warn semantics if seen / + return state->pwexpirewarnseen ? ERRPASSWORDEXPIREDWARN : EOK; @@ case LDAPACCESSEXPIREPOLICYWARN: ret = performpwexpirepolicy(state, state->domain, state->pd, state->accessctx->type, state->accessctx->idctx->opts); if (ret == ERRPASSWORDEXPIRED) {

ret = ERRPASSWORDEXPIREDWARN; + state->pwexpirewarnseen = true; + ret = EOK; } break;

------ This report was generated using AI technology. Always review AI-generated content prior to use

— Red Hat