BREAKING: CVE-2026-76578 lets an unauthenticated LDAP client become a FreeIPA admin

If your FreeIPA or Red Hat IdM LDAP ports are reachable without a login, an unauthenticated client can forge a Kerberos principal into the administrators group and run the directory as an admin. Red Hat scored CVE-2026-76578 at 9.8 (AV:N/AC:L/PR:N/UI:N) and says it reproduced the chain on a default, unmodified FreeIPA install. No fixed RPM is listed yet. Upstream FreeIPA master landed the ACI hardening today with Fixes: CVE-2026-76578 in the commit messages. Until your vendor package ships, treat open 389/636 from untrusted networks as an emergency.

This is the operator write-up. The HOL Guard evidence pack for CVE-2026-76578 is the source record.

What breaks

FreeIPA ships a self-service ACI named Users can create self-managed tokens under cn=otp. It allowed add when ipatokenOwner and managedBy matched SELFDN, but it did not constrain which object classes or attributes the new entry could carry. Combined with how 389 Directory Server evaluates anonymous binds against self-referential allow rules, a credential-less LDAP client could create a token-shaped entry that also smuggled a Kerberos principal, key material, password, and SID, then land that principal in the administrators group.

Red Hat's public statement is blunt: a prior uniqueness fix (CVE-2026-13097) blocked the literal admin name-collision trick, but it did not close the unauthenticated write path. The attacker no longer needs to impersonate the literal admin account. They pick their own name, join administrators, and get genuine admin LDAP rights (user add/delete demonstrated in Red Hat's own tests). On SID-enabled deployments that access also reaches other IdM services.

Upstream commit 316a3e45d2 (Alexander Bokovoy) is the surgical OTP fix: the ADD ACI now carries a targattrfilters clause that only permits OTP object classes (top, ipaToken, ipatokenTOTP, ipatokenHOTP) and forbids an injected aci. Attributes that need Kerberos or password object classes fail that filter. The commit notes that 389-ds does not consult targetattr on ADD, so targattrfilters is the lever that actually works. Legitimate ipa otptoken-add is unaffected.

That OTP constraint alone is not the whole story. Companion upgrades add an absolute deny for anonymous modifications on the IPA suffix and on o=ipaca when a CA exists (21-deny-anonymous-modify.update), harden self-service bind rules, and deny anonymous SID reads. The absolute deny uses userdn != "ldap:///all" because there is no ACI keyword that means "no credentials were sent"; empty-DN anonymous binds are the ones that fail ldap:///all. The patch text also warns that authmethod="none" means "do not check auth method" and would deny everyone if used as a deny clause, and that nsslapd-allow-unauthenticated-binds should stay off.

Who is not in scope

• Hosts that are only FreeIPA/IdM clients (SSSD against someone else's IPA). This is a server-side LDAP ACI issue on the IPA masters/replicas.
• IPA servers where ports 389/636 are not reachable from any untrusted network and anonymous binds are already rejected. You still want the package when it lands, but you are not in the emergency exposure class Red Hat describes.
• Deployments that only applied the earlier CVE-2026-13097 uniqueness / canonical-name collision fix. Red Hat says that patch does not remediate this CVE.
• CVE-2026-79678 (same-day FreeIPA Important): authenticated idp-add reaches a constrained eval() before the authz check for environment disclosure and memory DoS. Different bug, different preconditions. Not unauthenticated admin takeover.

What this is not

This is not a remote code execution bug in the IPA host OS, and it is not a Kerberos wire-protocol flaw. It is unauthenticated directory privilege escalation to FreeIPA administrators via LDAP ACIs. Red Hat reproduced admin LDAP read and admin-only write/delete; that is full IdM admin, not a sandbox escape story.

How to fix

There is no fixed ipa-server / IdM errata in the Red Hat CVE page yet (products still show affected / under investigation). Until the vendor package arrives:

1. Restrict LDAP to trusted hosts only: firewall TCP 389 and 636 so the internet and untrusted VLANs cannot reach IPA masters/replicas.
2. Disable anonymous LDAP binds if your clients do not require them. Red Hat says that blocks this specific path; confirm NIS/compat and any legacy anonymous readers before flipping it in production.
3. Confirm nsslapd-allow-unauthenticated-binds is off on the 389-ds instances backing IPA.
4. Watch for the FreeIPA / RHEL IdM update that ships install/updates/40-otp.update with the constrained self-managed-token ACI and 21-deny-anonymous-modify.update. Upstream master already has those files; package that train when your distro publishes it, then re-run ipa-server-upgrade / the normal IdM update path so the ACI update scripts apply.

Operator check you can run today from a host that should not be able to speak LDAP anonymously to the IPA server:

ldapsearch -x -H ldap://ipa.example.com -b "" -s base namingContexts
# Expect bind failure or referral policy you already chose.
# If this returns namingContexts from an untrusted network, treat LDAP as exposed.
rpm -q ipa-server 389-ds-base || true
# After the fix package: confirm the live ACI text includes
# targattrfilters on "Users can create self-managed tokens"
# and "Deny all modifications for anonymous binds".

Same-day sibling worth patching in the same window: CVE-2026-79678 (Important, CVSS 8.1). Any authenticated IPA principal can hit ipa idp-add before authorization and read process environment variables or DoS via memory exhaustion. On container images that left Directory Manager / admin passwords in the environment after first boot, that disclosure is worse. Red Hat says the eval() path cannot call functions (parentheses forbidden). Fix is still "upgrade when the package exists"; there is no config kill-switch.

References

• Red Hat CVE-2026-76578
• Bugzilla 2519522
• freeipa otp: constrain self-managed-token ADD
• freeipa aci: deny anonymous modifications
• Red Hat CVE-2026-79678 (sibling)
• Red Hat CVE-2026-13097 (prior collision fix; not sufficient alone)