REDHAT-BUG-2479031: Medium severity redhat/sssd vulnerability

Published May 18, 2026
·
Updated

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

Affected Software

1 affected component
redhat/sssd=2.12.0-1.el10

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Configuration

    Do not place pwd_expire_policy_warn before denial-capable rules; reorder ldap_access_order so restrictive checks run first, remove pwd_expire_policy_warn from the order, or use pwd_expire_policy_reject for expired accounts.

    LDAP-backed SSSD domain ldap_access_order = Place filter, host, rhost, or other restrictive rules before pwd_expire_policy_warn

Event History

May 18, 2026
Data Sourced
via Red Hat·03:53 AM
DescriptionSeverityAffected Software

Frequently Asked Questions

1

Which deployments are exposed?

Exposure is limited to LDAP-backed SSSD deployments using access_provider = ldap, a compatible password-expiration policy, and ldap_access_order with pwd_expire_policy_warn placed before restrictive rules such as filter or host checks.

2

What would an attacker need to exploit this?

The attacker needs a valid LDAP-backed account with an expired password. They also need a non-password authentication path, such as SSH public-key authentication, that invokes SSSD account and access checks.

3

How can I determine whether my configuration is affected?

Review the SSSD LDAP configuration for access_provider = ldap and inspect ldap_access_order. The affected ordering places pwd_expire_policy_warn before restrictive LDAP access rules, and the environment must permit a non-password login path for an expired LDAP account.

4

What can be done if a package fix is not available?

Place restrictive LDAP access rules before pwd_expire_policy_warn in ldap_access_order so those rules are evaluated before the warning result. Review non-password authentication paths for LDAP accounts with expired passwords until a released package fix is established.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203