Empty Equals Empty: CVE-2026-76578 Gives FreeIPA Admin to a Client With No Name

Red Hat ran this exploit twice before publishing it. The second run came from a machine with no prior access to anything, against a default, unmodified FreeIPA install, and it ended with a working set of administrator credentials that the attacker chose the name for.

That is CVE-2026-76578, disclosed on 8 September 2026 with a preliminary CVSS of 9.8. I have spent a lot of hours writing exploit chains for identity systems, and this one has a quality I rarely get to see outside a CTF: there is no memory corruption, no race, no timing window, no payload. There is a comparison between two empty strings that returns true.

The bug is that nobody is somebody

Two defects are needed, and neither is dramatic on its own.

The first lives in FreeIPA. The product ships a default access control instruction so a user can manage their own one time password token. Red Hat's description of the failure is blunt: the self managed OTP token ACI "does not require authentication and does not restrict which attributes may be added alongside the token entry." Two problems in one sentence. The rule never checks that you logged in, and it never constrains what else you write into the entry you are creating.

The second lives underneath, in 389 Directory Server, tracked as CVE-2026-76560 at CVSS 7.5. The directory offers a rule type that is supposed to mean "only the authenticated owner of this entry may touch it." The access control engine implements that ownership test as a plain text comparison between the client's bind name and a stored value. A client that never authenticated carries an empty name. An entry the attacker just created can carry an empty ownership field. Empty matches empty. The ownership check passes because the attacker is nobody, and the entry belongs to nobody.

Chain them and the sequence is four steps. Reach LDAP on 389 or 636 without credentials. Create an OTP token entry with the ownership attributes left blank. Satisfy the ownership rule by virtue of having no identity at all. Write an arbitrary Kerberos principal and a password of your choosing into that same entry, where it lands in the administrators group.

Red Hat says the result is genuine administrator group membership and reusable administrator credentials. On SID enabled deployments it gets worse: the attacker can pull a Kerberos ticket carrying authorization data, which extends reach to the server's HTTP services and to Dogtag, the certificate authority FreeIPA bundles. An attacker with the CA is no longer stealing credentials. They are issuing them.

Red Hat also notes that Red Hat Directory Server ships no rule of that shape by default, so the 389-ds flaw alone is mostly theoretical. FreeIPA is the deployment that writes exactly that rule. The two products are safe apart and dangerous together, which is why this sat in plain sight long enough to be found by Gia Bui of Calif rather than by either vendor's own review.

The unglamorous prerequisite

Every published mitigation reduces to the same sentence: can an untrusted host talk to your IPA masters and replicas on 389 and 636?

Red Hat's interim advice is to firewall those ports to trusted systems and to disable anonymous LDAP binds where nothing depends on them. That is good advice and it is also a confession. The exploit needs no credentials, no user interaction, no prior foothold and no social engineering. Network reachability is the entire attack surface.

If you want a five second answer, do not go looking for a Shodan tally. Nobody has published a credible internet wide count of exposed FreeIPA servers, and I would not trust one that appeared this week. Run ldapsearch -x -H ldap://ipa.example.com -b "" -s base namingContexts from a segment that has no business speaking LDAP. If naming contexts come back, you match Red Hat's stated preconditions and you should treat the box as at immediate risk.

Most teams will find that their IPA masters are not on the internet. Then they will find that the flat internal network, the developer VPN pool, the CI runners and the guest VLAN can all reach port 389 anyway, because in 2015 somebody needed sssd to work and never came back to narrow it. That is the shape of nearly every identity compromise I have worked on. Reachability accumulates quietly, and nobody owns it.

Patch the bug, keep the attacker

Here is the part that should change how you plan the next week, and the part almost nobody covered.

The advisories and bug reports publish no detection guidance and no indicators of compromise. The Hacker News, which broke down both halves on 8 September, flagged two questions left unanswered in all published material. Does updating 389-ds alone stop the attack on a server whose ipa packages are still old? And does applying a fix remove an identity that an attacker planted beforehand?

The answer to the second one is almost certainly no, and you should behave as though it is a definite no.

Think about what the exploit produces. Not a shell. Not a beacon. Not a file on disk. It produces a Kerberos principal with a password, sitting in the administrators group, that looks exactly like every other principal in your directory because it is exactly like every other principal in your directory. Nothing about that object is tainted by the flaw that created it. Upgrade to FreeIPA 4.13.4, apply the 389-ds errata, and the principal survives the reboot with full admin rights, because a patch fixes code paths and does not audit data.

That is what I would do if I hit an IPA master on a red team: create the principal, take the keytab, do nothing else for a month, and let the customer's own patch cycle convince them the incident is over. Persistence you install before the fix is persistence the fix legitimizes.

So the remediation task is not one item, it is two. Patch, then reconcile. Pull the current membership of the administrators group and every privileged role, pull creation timestamps on principals and on OTP token entries, and compare against your own provisioning records. Any admin principal whose creation you cannot tie to a ticket, a person or a pipeline is an incident until proven otherwise. Look particularly for token entries with blank ownership attributes, since that is the artifact the chain has to leave behind.

Red Hat and the FreeIPA project do not fully agree on how bad this is, and that disagreement matters here. The project's framing is narrower: the injected identity cannot already exist, the earlier fix for CVE-2026-13097 in 4.13.3 blocks takeover of the real admin account, and the chain "may be used as a stepping stone" toward administrative privileges. Red Hat's framing is that you get reusable administrator credentials. Practically, an attacker choosing their own name is worse for you than one impersonating admin, not better. A collision with a known account is something a competent SOC might notice. A brand new principal called svc-backup-replica is something your directory will defend.

Why your logs are not going to save you

Ask what this looks like in telemetry. An LDAP connection arrives from an internal host. An anonymous bind succeeds, because anonymous binds are supposed to succeed. An add operation is permitted, because the ACI permits it. A modify operation is permitted, because the ownership check passed. Zero failed authentications. Zero brute force pattern. No malformed packets, because nothing is malformed. The traffic is not an attack against LDAP, it is LDAP.

This is the same structural problem I wrote about in the SharePoint forged JWT chain that produces no login event, and the same one behind TheHatman's Entra directory dumps, which needed no exploits at all. When the abuse is made of valid protocol operations, signature based detection has nothing to sign. Behavioural baselining does not help either, because a directory server's normal day is a flood of binds, adds and modifies from every host in the estate.

What does work is planting something that has no legitimate reason to be touched.

Where deception fits, specifically

Two placements are worth your time on an identity authority.

First, decoy principals. A directory with ten thousand real objects can hold a handful of fake privileged accounts that no process, script or admin ever authenticates as. They exist for one purpose: any authentication attempt, any password spray hit, any enumeration that ends in a bind as one of those names is an attacker, with no ambiguity to triage. That is the zero false positive property, and on an identity store it is stronger than anywhere else, because you control the entire population of things that should ever touch those objects. If an attacker uses freshly minted admin rights to enumerate the directory, which is always the next step, they cannot tell the decoys from the crown jewels. We walked through the enumeration sequence attackers actually run in the Aurora Files port 8888 Active Directory playbook, and it is the same five commands every time.

Second, the reachability problem itself. The prerequisite for CVE-2026-76578 is an untrusted host reaching LDAP. A decoy LDAP listener on the segments where nothing should be scanning for directory services turns that prerequisite into a tripwire. MineField decoy services exist for this: a service that answers on a port, holds no data, serves no production function, and reports the first connection. When somebody sweeps your VLANs for 389 and 636, you find out during the reconnaissance, not after the principal is in the administrators group. That matters more than it used to, given the breakout times in CrowdStrike's 2026 threat report.

Neither of these replaces patching. Both of them cover the window between disclosure and the change window your platform team can actually get, which for a production identity authority is rarely measured in hours.

Before Friday

Patch to FreeIPA 4.13.4 and apply the 389-ds updates for your platform. RHEL 10 has 389-ds-base-3.2.0-10.el10_2 via RHSA-2026:64785, and RHEL 7 through 10 IPA and IdM components are in scope. While you are there, 4.13.4 also fixes CVE-2026-79678, an 8.1 issue where idp-add reaches a constrained eval() before the authorization check, letting any authenticated account read the server process environment one variable at a time. If you run the official FreeIPA container image, that is a real problem, because first boot commonly takes the Directory Manager and admin passwords as environment variables. Confirm they are gone from the running process.

Then firewall 389 and 636 to hosts that need them, disable anonymous binds if nothing breaks, and run the administrators group reconciliation described above. Do the reconciliation even if you patched fast. Especially if you patched fast, because a clean scan after the fix tells you nothing about the week before it.

If you want to see what a decoy principal looks like sitting inside a real directory, and how fast it fires when someone touches it, book a walkthrough with our team and bring your own directory layout to the call.