The anonymous client passes the ownership check by being nobody

Disclosure: this site is written with Claude, which is made by Anthropic. One of the three vulnerabilities below was reported by a firm working with Anthropic. Read the credit lines knowing that.

On 8 September 2026, three vulnerabilities were disclosed across FreeIPA and 389 Directory Server:

• CVE-2026-76578 — FreeIPA, critical, CVSS 9.8 (preliminary)
• CVE-2026-76560 — 389 Directory Server, 7.5
• CVE-2026-79678 — FreeIPA idp-add, important, 8.1

FreeIPA is what decides who may log in across a Linux domain. It keeps every identity in a 389 Directory Server database reached over LDAP, and Red Hat ships it as Identity Management.

So this is not a flaw in an application. It is a flaw in the thing the applications ask.

Two bugs that are only dangerous together

Take them separately first, because separately neither looks like much.

In FreeIPA, there is an access control instruction permitting unauthenticated users to manage their own one-time-password token. That sounds reasonable — enrolling a token is something you do before you have credentials. The rule does not restrict what else can be written alongside it.

In 389 Directory Server, the access rule that enforces "only the authenticated owner of this entry may modify it" compares names as plain text.

2 rules, each defensible alone. FreeIPA lets unauthenticated users manage their own one-time-password token. 389 Directory Server checks ownership by comparing names as plain text. An unauthenticated client has an empty name; the entry it just created has an empty owner; the check finds them equal and permits the write. The attacker does not defeat the check — the attacker satisfies it, by being nobody.

The attacker passes the ownership test by being nobody. The empty string is the empty string.

From there the same write attaches a Kerberos identity and a password to the entry, and puts it in an administrative group. An anonymous client with no login history now has domain credentials it can reuse.

That is a very elegant bug, and elegant is exactly the wrong thing for it to be.

What "anonymous" means here

Worth being precise, because the word does a lot of work.

Anonymous does not mean an attacker who guessed a password, or one holding a low-privilege account, or one who phished a user. The attacker model is a client that has never authenticated, has no account and no login history, reaching the directory service over the network. Being able to talk to it is the only precondition — which is what makes this a 9.8 rather than a 7.

The patch matrix has holes in it

Upstream FreeIPA is fixed in 4.13.4, and the chain was reproduced on 4.13.1. Which earlier versions are affected has not been stated.

Downstream, as of disclosure:

If you run Red Hat Identity Management on RHEL 9, there is currently nothing to install for either half.

And nobody has published whether the 389-ds update alone stops the attack on a host still running an outdated ipa package. That is the single most useful question for anyone in the middle of this, and it is open.

The question nobody has answered

Patching closes the door. It does not tell you whether somebody already came through it.

The attack creates an identity. One created before the patch survives the patch, because it is now a legitimate row in your directory with legitimate administrative group membership, and there is nothing structurally wrong with it any more. 0 detection rules have been published, 0 indicators of compromise, and no guidance on whether patching removes attacker-created entries or how anyone would find one.

So for an identity system — the one place where "who is allowed in" is the entire product — the state of the art this week is: install the update, and hope.

The pattern is familiar from the Entra ID flaw earlier this month, where the severity was maximal and the customer-side action was nothing. Here there is something to install, and still nothing to look for.

Credit, and the disclosure

Gia Bui of Calif reported the FreeIPA chain and the directory-server flaw. Calif, working with Anthropic, reported the idp-add vulnerability.

That second credit is why the disclosure sits at the top of this article. Anthropic makes the model this site is written with, so a piece that praises research Anthropic contributed to is not a neutral document, and you should be able to see that rather than work it out.

For what it is worth, the finding stands on its own: two access rules that each look defensible, combining into anonymous domain administration, is good work regardless of who paid for it.

What to do

• Update FreeIPA to 4.13.4 where you run it upstream.
• Apply RHSA-2026:64785 on RHEL 10. On RHEL 9 and Fedora, watch for it — there is nothing yet.
• Do not assume the 389-ds fix alone is sufficient if your ipa packages are behind. Nobody has confirmed that either way.
• Audit your administrative groups by hand. Not for indicators, because there are none — for members you cannot account for. This is the only detection available.
• Check for OTP token entries with empty or unexpected ownership, which is the artefact the chain leaves behind.
• Restrict who can reach the directory service on the network. The precondition is reachability, so that is the compensating control.

What is not established

• Which versions before 4.13.1 are affected. Not stated.
• Whether 389-ds updates alone stop the attack on outdated ipa packages.
• Whether patching removes attacker-created identities, or how to find them.
• Any indicator of compromise or detection rule. None published.
• Whether it has been exploited. None of the advisories or bug reports describe a real attack.