FreeIPA Flaw Chain Lets Anonymous Clients Create Reusable Administrator Credentials

A flaw in FreeIPA lets a client that has never logged in create a Kerberos identity of its own choosing in the directory and end up in the administrators group, Red Hat says.

FreeIPA is the system that determines who may log in across a Linux domain and maintains all identities in a 389 Directory Server database accessed via LDAP. The attack needs a second flaw in that database software.

The FreeIPA project has already fixed its side in version 4.13.4. Red Hat says it reproduced the chain twice on a default installation, most recently on a machine with no access at all.

Red Hat tracks the FreeIPA flaw as CVE-2026-76578 and rates it critical, with a CVSS score of 9.8. The same page says that score is preliminary and subject to review.

Red Hat ships FreeIPA as its Identity Management product, where the package is called ipa.

FreeIPA ships an access control rule, called an ACI, that lets a user manage their own one-time-password token. The rule does not require the client to have logged in, nor does it limit what else may be written alongside the token.

That only becomes dangerous because of the second flaw. 389 Directory Server has a rule type meant to say “only the authenticated owner of this entry.” It compares the client’s name against a stored value as plain text, and a client that has not logged in has an empty name, which matches an empty stored value.

So an anonymous client can create a token entry with the ownership fields left blank, pass the ownership check by being nobody, and write a Kerberos identity and password alongside it.

Red Hat scores the directory-server flaw, CVE-2026-76560, at 7.5, and says Red Hat Directory Server ships no rule of that shape by default. On its own, the flaw matters only where a deployment has written such a rule.

FreeIPA is such a deployment. Its shipped default rule is exactly that shape, which is why the chain works against an untouched install. That connection is our reading of two advisories that describe the halves separately.

Red Hat also reproduced the directory-server defect on its own, on a plain 389-ds build with no FreeIPA parts installed, and a control test using a value that was not empty was correctly refused. That places the defect in the access-control engine rather than in anything FreeIPA does.

The technique first reported to Red Hat impersonated the real admin account by creating a Kerberos name that matched it. An earlier fix for CVE-2026-13097 blocked that collision but left the underlying unauthenticated write in place. The attack now works under a name the attacker picks instead, Red Hat says, “reaching the same practical outcome.”

That earlier flaw, fixed in FreeIPA 4.13.3, was a different problem. The check that Kerberos names are unique did not allow different ways of writing the same name, which allowed a user with write access to create a service identity that impersonated an existing privileged one.

The two projects describe the result differently. Red Hat calls it genuine administrator-group membership and reusable administrator credentials.

The FreeIPA project puts it more narrowly, stating that the injected identity must not already exist, that the CVE-2026-13097 fix prevents existing accounts from being taken over, and that the attack “may be used as a stepping stone” to administrative privileges.

Red Hat says it ran the chain against a stock FreeIPA container image running version 4.13.1 and checked the results with standard administrator-only commands rather than trusting the exploit’s output. None of the advisories or bug reports describe the flaw being used in a real attack.

For deployments using Windows-style security identifiers, Red Hat says the attacker can also obtain a Kerberos ticket containing authorization data, thereby extending access to the server’s HTTP and Dogtag services. Dogtag is FreeIPA’s built-in certificate authority.

A Second, Separate Flaw

Red Hat disclosed a second FreeIPA flaw alongside these, CVE-2026-79678, which has nothing to do with the chain above. It rates this one important, with a score of 8.1.

The idp-add command passes two values the caller supplies, an organization name and a base URL, into a Python eval() call. That call runs before the permission check meant to limit the command to identity-provider administrators, so any account on the server can reach it, whatever its privileges.

The call is limited by a pattern that forbids brackets, which stops any function being called. Red Hat says “no code execution is possible.”

What an attacker can do is read the server process’s environment variables one at a time by observing the error the server returns, and use up the server’s memory with a short arithmetic expression.

How much that matters depends on how FreeIPA was installed, Red Hat says. On a normal package-based install, the process environment holds only documented paths and settings. Container installs are different.

The official FreeIPA server image often takes the Directory Manager and administrator passwords as environment variables at first boot, and those passwords could be exposed if they remain after setup finishes.

Red Hat credits Gia Bui of Calif with reporting the FreeIPA chain and the directory-server flaw, and credits Calif working with Anthropic for the idp-add flaw.

What Administrators Can Do Now

The fix has arrived in three different places at three different times, so the answer depends on which piece of software you are patching.

No advisory for plain Red Hat Enterprise Linux 9 appeared in that list of fourteen. That is what the bug record showed on 8 September, not a statement that the release has no fix coming.

Until a fixed package is available, Red Hat gives two temporary steps for the chain:

1. Restrict access to the LDAP service (typically ports 389 and 636) to hosts you trust, using firewall rules or network segmentation.
2. Turning off anonymous LDAP binds blocks this particular path, Red Hat says, but check first that nothing else in your deployment needs them.

For the idp-add flaw, there is no such option. Red Hat says no configuration setting keeps an ordinary authenticated account away from that code, and that a fixed package is required. It adds that anyone running container installs should verify that the password set at first boot is no longer present in the running process environment.

The published material leaves two questions unanswered. Neither Red Hat nor the FreeIPA project says whether 389-ds updates, on their own, stop the FreeIPA attack on a server whose ipa packages are still outdated.

And neither says whether applying a fix removes an identity an attacker created beforehand, or what an administrator should look for to find out.

Neither the advisories nor the bug reports publish detection rules or indicators.