Red Hat: FreeIPA Flaw Chain Grants Admin to Anonymous Users

FreeIPA, the open source identity management system that determines who may log in across a Linux domain, contains a flaw chain that can let a client that has never logged in create a Kerberos identity of its own choosing and end up in the administrators group, according to Red Hat. FreeIPA keeps all identities in a 389 Directory Server database that is accessed over LDAP, and the attack also needs a second defect in that database software. Red Hat tracks the FreeIPA half as CVE-2026-76578 and rates it critical with a CVSS score of 9.8, while noting that the score is preliminary and subject to review. The FreeIPA project has already fixed its side in version 4.13.4.

The first issue is an access control rule called an ACI that FreeIPA ships. This rule lets a user manage their own one-time-password token, but it does not require that the client has logged in, and it does not limit what else may be written alongside the token. By itself this would not be enough. The second flaw is in 389 Directory Server. Its access control engine has a rule type meant to say only the authenticated owner of an entry may change it. It compares the client's name against a stored value as plain text. A client that has not logged in has an empty name, and that empty value matches an empty stored value. As a result, 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 does not ship a rule of that shape by default, so on its own the flaw matters only where a deployment has written such a rule. FreeIPA is exactly such a deployment because its shipped default rule has that shape. Red Hat reproduced the full chain twice on a default installation, most recently on a machine with no access at all, and also reproduced the directory server defect on a plain 389-ds build with no FreeIPA parts installed; a control test using a non-empty value was correctly refused. This 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, which Red Hat says reaches 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, so a user with write access could 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 states 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 results with standard administrator-only commands rather than trusting exploit 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, extending access to the server's HTTP and Dogtag services, where Dogtag is FreeIPA's built-in certificate authority.

Separately, Red Hat disclosed CVE-2026-79678, an important flaw with a score of 8.1 that has nothing to do with the chain. The idp-add command passes two values supplied by the caller, 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 regardless of privileges. The call is limited by a pattern that forbids brackets, which stops any function from being called, and 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. On a normal package-based install, the process environment holds only documented paths and settings. On the official FreeIPA server image, the Directory Manager and administrator passwords are often taken 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.

The fix has arrived in three places at three different times. For FreeIPA from the project, install FreeIPA 4.13.4, which fixes both FreeIPA flaws, but the release notes carry no date and do not say which earlier versions are affected. For 389-ds-base on Red Hat Enterprise Linux and Red Hat Directory Server, use the advisory for the release; fourteen advisories were published on 8 September between 01:56 and 05:07 UTC, and RHSA-2026:64785 covers Red Hat Enterprise Linux 10 with 389-ds-base-3.2.0-10.el10_2. That advisory is rated critical and covers four more 389-ds flaws besides this one. For ipa packages on Red Hat Enterprise Linux, no fixed version or advisory was listed when checked on 8 September. On Fedora, the tracker was marked ON_QA on that date. No advisory for plain Red Hat Enterprise Linux 9 appeared in the list of fourteen, but that was 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. First, restrict access to the LDAP service, typically ports 389 and 636, to hosts you trust using firewall rules or network segmentation. Second, turning off anonymous LDAP binds blocks this particular path, 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 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 a