Dateline: September 8, 2026
A client that never logs in should not be able to name itself an administrator. On a default FreeIPA server, it can.
Red Hat says two chained flaws let an anonymous LDAP client write a Kerberos identity of its own choosing into the directory and land in the administrators group. FreeIPA is the software that decides who may log in across a Linux domain, so a break here is a break in the front door for the whole environment. The project has shipped a fix. Many production servers have not applied it yet.
What Happened?
FreeIPA stores every identity in a 389 Directory Server database reached over LDAP. Two separate weaknesses line up to defeat it.
The first is a FreeIPA access rule, an ACI, that lets a user manage their own one-time-password token. It does not check that the client logged in, and it does not limit what else gets written next to the token.
The second lives in 389 Directory Server. A rule type meant to mean “only the authenticated owner of this entry” compares the client name against a stored value as plain text. A client that never logged in has an empty name, and an empty name matches an empty stored value. So an anonymous client creates a token entry with the ownership fields left blank, passes the ownership check by being nobody, and writes a Kerberos identity and password alongside it.
Red Hat tracks the FreeIPA half as CVE-2026-76578, rated critical at CVSS 9.8, and notes the score is preliminary. The directory server half is CVE-2026-76560 at 7.5. On its own the directory bug matters only where a deployment ships a rule of that exact shape. FreeIPA ships one by default, which is why an untouched install is exposed.
A third, unrelated FreeIPA flaw was disclosed at the same time. CVE-2026-79678, rated 8.1, passes caller-supplied values into a Python eval() call before the permission check runs. Red Hat says no code execution is possible, but an attacker can read process environment variables one at a time and exhaust server memory. Container installs that keep setup passwords in the environment are the real worry here.
What’s the Impact?
An attacker needs no account and no prior foothold. Reachability to the LDAP service is enough.
On deployments that use Windows-style security identifiers, Red Hat says the attacker can also pull a Kerberos ticket carrying authorization data, which extends access to the server HTTP and Dogtag certificate authority services. That turns a directory write into a path toward issuing certificates.
Two questions stay open in the published material. Nobody has said whether patching the directory server alone stops the attack when the ipa packages are still old. And nobody has said whether applying the fix removes an identity an attacker already planted. Treat a patched but previously exposed server as one that still needs an audit of its administrator group.
There are no public reports of this being used in a live attack yet. That tends not to last once a critical identity flaw is documented.
How to Avoid This
The FreeIPA project fixed both its flaws in version 4.13.4. Move there first.
Until a fixed package reaches your distribution, Red Hat gives two temporary steps for the chain. Restrict the LDAP service, typically ports 389 and 636, to hosts you trust using firewall rules or network segmentation. Turn off anonymous LDAP binds, after you confirm nothing else in your deployment depends on them.
The eval() flaw has no config workaround. It needs the patch. If you run the official container image, verify the Directory Manager and administrator passwords set at first boot are no longer sitting in the running process environment.
For detection, no vendor detection rules or static indicators have been published. Watch behavior instead. Flag any addition to the administrators group, any new Kerberos principal, and any one-time-password token entry created over an unauthenticated LDAP connection. Review who belongs in your privileged groups now, not after the next audit.
