Two separate bugs, one in FreeIPA and one in the directory server underneath it, combine to let a client with no credentials at all write itself into the administrators group. Red Hat has fixed part of it. Here's what's actually confirmed.
What happened
FreeIPA is the identity management layer that decides who can log into a Linux domain. It stores every identity in a 389 Directory Server database, reached over LDAP. Red Hat disclosed that a client who has never authenticated can still write a new identity into that database, name it whatever they want, and end up in the administrators group.[1] It takes two flaws working together, not one.
Red Hat says it reproduced the chain twice on a default installation, most recently starting from a machine with no access at all.[1] The FreeIPA project has already shipped a fix for its half in version 4.13.4.[2]
How the chain actually works
FreeIPA ships an access control rule, an ACI, that lets a user manage their own one-time-password token. That rule was never meant to require a login first, and it didn't restrict what other fields could ride along with the token write.[2] By itself, that's a narrow hole.
The second flaw is what turns it into something serious. 389 Directory Server has a rule type meant to mean "only the authenticated owner of this record." According to Red Hat's own advisory, that evaluator compares the client's bind name against a stored attribute value as plain text[3], and an anonymous client's bind name is an empty string. An empty string matches an empty stored value. The check that was supposed to require a real, authenticated identity ends up satisfied by nobody at all.
Chain the two together and an anonymous LDAP client can create a token entry with the ownership fields left blank, pass the ownership check by matching on emptiness, and write a Kerberos identity and password alongside the token in the same operation.[2] Red Hat separately reproduced the directory-server defect on a plain 389-ds build with no FreeIPA installed at all, and confirmed a control test using a non-empty value was correctly rejected — which is how they narrowed the defect down to the access-control engine itself rather than anything specific to FreeIPA.[1]
Why this isn't a brand-new discovery from scratch
There's a prior chapter here worth knowing. An earlier flaw, CVE-2026-13097, let an attacker impersonate the literal admin account by creating a Kerberos name that collided with it; FreeIPA fixed that collision in version 4.13.3.[1] That fix blocked the specific trick of overwriting an existing account, but it didn't touch the underlying unauthenticated write. Red Hat says the attack still works, just under a name the attacker picks instead of the real admin's name, "reaching the same practical outcome."[1]
The FreeIPA project's own description is narrower than Red Hat's. FreeIPA states the injected identity must not already exist, that the CVE-2026-13097 fix prevents existing accounts from being taken over, and that the technique "may be used as a stepping stone" toward administrative privileges.[2] Red Hat calls the outcome genuine administrator-group membership with reusable administrator credentials.[1] Both descriptions can be true at once — they're emphasizing different parts of the same chain.
CVE identifiers and severity
Red Hat tracks the FreeIPA half as CVE-2026-76578, rating it critical with a CVSS v3.1 base score of 9.8 (vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), and notes the score is preliminary and subject to review.[3] The underlying weakness is classified as CWE-306, Missing Authentication for Critical Function.[3] The directory-server half is tracked as CVE-2026-76560, scored 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N), classified under CWE-863, Incorrect Authorization.[4] Red Hat's own statement notes that Red Hat Directory Server does not ship an ACI of the vulnerable shape by default — real-world impact depends on whether a given deployment defines one, and FreeIPA's shipped default rule happens to be exactly that shape.[4]
A second, unrelated flaw: CVE-2026-79678
Red Hat disclosed a third issue alongside the chain, unconnected to it. FreeIPA's idp-add command passes caller-supplied organization name and base URL values into a Python eval() call, and that call runs before the permission check meant to restrict the command to identity-provider administrators.[2] Any authenticated account, regardless of privilege, can reach it.
The impact is bounded by design, not luck. Red Hat's advisory is explicit that the eval() call is constrained by a pattern that forbids parentheses, which blocks any function from being invoked, so no code execution is possible.[5] What remains is that an attacker can read the server process's environment variables one at a time by watching how the server responds to errors, and can exhaust server memory with a short arithmetic expression.[5] Red Hat scores this one 8.1 and rates it important rather than critical, specifically because code execution is off the table.[5]
How much this matters depends heavily on deployment method. On a standard package-based install, the process environment holds only documented paths and settings, according to Red Hat.[5] Container installs are a different story: the official FreeIPA server image commonly takes Directory Manager and administrator passwords as environment variables at first boot, and those could remain exposed if they're not cleared after setup.[5]
Exploitation status
It's worth being precise here rather than reaching for the scariest available word. Red Hat says it independently reproduced the FreeIPA/directory-server chain against a stock, unmodified FreeIPA installation, and separately reproduced the directory-server defect on its own.[1][3] That is confirmed proof-of-concept work by the vendor, run under controlled conditions. None of the advisories or the linked bug report describe the flaw being used in a real-world attack.[1] Treat this as a serious, vendor-confirmed vulnerability chain with no reported active exploitation, not as an incident that has already happened somewhere.
Affected versions and fix status
The fix picture is split across three components and three timelines. FreeIPA's own fix for both the chain flaw and the idp-add flaw shipped in version 4.13.4; the release notes don't specify a date or list which earlier versions are affected, only that this release addresses both issues.[2] On the 389 Directory Server side, Red Hat published a batch of advisories covering Red Hat Enterprise Linux and Red Hat Directory Server packages, including one rated critical for Red Hat Enterprise Linux 10.[1] Fedora's own 389-ds-base update was still moving through testing as of the reporting reviewed for this article.[1] Red Hat's own ipa package builds for Red Hat Enterprise Linux had no listed fixed version at the time this was checked.[1]
What administrators should do now
Until every affected package is patched in your environment, Red Hat's guidance for the chain is straightforward: restrict network access to the LDAP service, typically ports 389 and 636, to hosts you actually trust, and disable anonymous LDAP binds if your deployment doesn't need them.[3] Check first — some environments rely on anonymous binds for legitimate purposes, and turning them off blind can break things.
For the idp-add flaw, there's no configuration workaround. Red Hat is direct about this: no setting keeps an ordinary authenticated account away from that code path, and a patched package is required.[5] If you're running the official container image, check whether the Directory Manager or admin password supplied at first boot is still sitting in the running process's environment after setup finishes.[5]
What's still unclear
Two things the published advisories don't address. Neither Red Hat nor the FreeIPA project states whether patching 389-ds on its own, without also updating the ipa packages, is enough to stop the chain on a server whose FreeIPA install is still outdated. And neither says whether applying the fix retroactively removes an identity an attacker might have already planted, or what an administrator should look for to check. If you're running FreeIPA with LDAP reachable from an untrusted network, the honest answer right now is that detection is on you.
Security takeaway
This chain is a reminder that access control bugs rarely need to be complicated to be dangerous. One rule didn't require a login it should have. Another rule compared two blank values and called that a match. Neither flaw alone was catastrophic — Red Hat's own scoring reflects that RHDS ships no vulnerable ACI by default — but FreeIPA's default configuration happened to combine them into a path from zero credentials to genuine administrator access. If you run FreeIPA or Identity Management, the fix schedule is uneven across components right now, so the network-level mitigations aren't optional extras; they're the thing standing between an anonymous LDAP connection and your directory's administrators group until every package in your stack is patched.
Sources & References
- [1] The Hacker News — "FreeIPA Flaw Chain Lets Anonymous Clients Create Reusable Administrator Credentials" — Sept 8, 2026 — View source
- [2] FreeIPA Project — "FreeIPA 4.13.4" release notes — Official release notes
- [3] Red Hat Product Security — CVE-2026-76578 — Red Hat CVE database entry
- [4] Red Hat Product Security — CVE-2026-76560 — Red Hat CVE database entry
- [5] Red Hat Product Security — CVE-2026-79678 — Red Hat CVE database entry
Disclaimer: CVSS scores cited here are marked preliminary by Red Hat and subject to review. No advisory reviewed for this article reports active exploitation in the wild.
Technical Discussion & Feedback (0)
Leave a Comment (Authenticated Users)