SURIQ
A privilege escalation flaw disclosed today does not live in code you can patch away. It lives in a default setting that is probably already active on your servers. Red Hat assigned CVE-2026-14474 to the System Security Services Daemon (SSSD), the service that most enterprise Linux hosts use to authenticate against a central directory. When SSSD resolves sudo rules over LDAP and nobody has told it where to look, it walks the whole directory. That one default converts the ability to write an object anywhere in the directory into root across the fleet.
Red Hat scored it 8.8 (high), reachable over the network by an already-authenticated user who starts with only low privileges, and classified it as CWE-1188, insecure default initialization. That classification is the whole story. This is not a bug an attacker triggers with a crafted packet. It is a footgun that ships pointed at your foot.
What the flaw actually does
SSSD can resolve sudo rules from a directory using the sudo_provider setting. Sudo rules in LDAP are stored as sudoRole objects, which say who may run what, and on which hosts. Administrators are meant to keep those objects in a dedicated container, for example ou=sudoers,dc=example,dc=com, and point SSSD at it with the ldap_sudo_search_base option.
The flaw is what happens when that option is left unset. Rather than failing closed or narrowing the scope, SSSD falls back to the top of the domain and reads the full subtree, per Red Hat's bug report. Every sudo rule anywhere in the directory now counts. An authenticated user who can add an object to any branch they control can create one that hands their own account root, mark it to apply to all machines, and watch every host that reads this directory obey it.
Which sudo providers are exposed
The exposure follows the code path, not the directory brand. The ldap and ad (Active Directory) providers both run the affected lookup, because the Active Directory provider hands sudo resolution to the same routine. The ipa provider, used with FreeIPA, resolves sudo a different way and is not affected.
| SSSD sudo provider | Exposed by default | Why |
|---|---|---|
| ldap | Yes | Searches the entire directory tree for sudo rules when no search base is set |
| ad (Active Directory) | Yes | Hands sudo lookups to the same LDAP routine |
| ipa (FreeIPA) | No | Uses a separate sudo resolution path that is not affected |
Red Hat lists the affected package across Red Hat Enterprise Linux versions 7 through 10, and in OpenShift Container Platform 4. SSSD is not a Red Hat exclusive, though. It is the standard directory client on Fedora, AlmaLinux, Rocky, and is widely deployed on Ubuntu and Debian hosts joined to LDAP or Active Directory. If your Linux fleet pulls sudo rules from a directory, this is your default to check.
Why delegated administration makes this worse
The precondition, write access to some part of the directory, sounds like a high bar until you remember how large directories are actually run. Delegated administration is the norm: the team that owns one organizational unit gets write access to that branch so they can manage their own users, groups, and service accounts. That delegation is normally treated as safe, because a branch admin can only touch their branch.
This flaw inverts that assumption. With the sudo search base unset, an object written into any delegated branch is still read fleet-wide. The more you have delegated write access down the tree, the larger the set of accounts that can quietly escalate to root everywhere. A single compromised low-privilege service account with write access to one container becomes a path to the whole estate. That is the real blast radius, and it is bigger in mature, heavily-delegated environments than in small flat ones.
Set the search base today, then hunt the directory
At the time of writing there is no fixed SSSD package published, and the Red Hat tracker is still open. Waiting for a patch is the wrong reflex here anyway, because both the exposure and the fix already live in your configuration. Two actions, in order.
First, close the default. On every host that uses an ldap or ad sudo provider, set ldap_sudo_search_base in sssd.conf to the specific container that holds your sudo rules, then restart the service and clear the SSSD cache. Confirm no host is running a sudo provider with that option blank. This is the change that actually removes the exposure, and you can make it now.
Second, treat the directory as the crime scene, not just the hosts. A planted sudo rule sits in the directory and keeps applying to every host that reads it until someone deletes the object, so patching a host does not undo it. Enumerate every sudoRole object in your directory and flag any that sit outside your intended sudoers container, and any that grant root broadly (a sudoUser or sudoHost value of ALL is the tell). In MITRE ATT&CK terms this is abuse of an elevation control mechanism (T1548) reached through account manipulation (T1098), so your detection should watch for new or modified sudo objects in the directory and for accounts suddenly resolving root on hosts they never had before. Alerting on directory writes to sudo objects, and on unexpected root sessions, is what catches an abuse of this in the window before you have locked every config down.
No public exploitation has been reported as of publication, and there is no public proof-of-concept. That is the good news and the reason to move now: the fix is a settings change you control, and the honest window to make it is before someone writes the object rather than after.