"reaching the same practical outcome," Red Hat said — a concise summary of how two separate defects combined to let an unauthenticated client create a Kerberos identity and end up in FreeIPA's administrators group.
CVE-2026-76578: the FreeIPA–Kerberos chain in plain terms
Red Hat has flagged a critical vulnerability in FreeIPA as CVE-2026-76578, assigning a preliminary CVSS score of 9.8. The flaw chain lets a client that has never logged in create a Kerberos identity of its own choosing in the directory and become a member of the administrators group. FreeIPA's own project fixed its component in version 4.13.4; Red Hat says it reproduced the chain twice on a default installation and most recently on a machine "with no access at all."
The chain exploits a shipped access-control rule (an ACI) that allows a user to manage their one-time-password token. That rule does not require the client to have authenticated, nor does it prevent writing additional attributes alongside the token. An attacker can supply a token entry and write a Kerberos principal and password beside it, creating reusable administrator credentials. Red Hat describes the outcome as genuine administrator-group membership and reusable administrator credentials. The FreeIPA project frames the result more narrowly, noting the injected identity must not already exist and that the earlier CVE-2026-13097 fix prevents taking over existing accounts, while acknowledging the technique "may be used as a stepping stone" to administrative privileges.
389 Directory Server defect CVE-2026-76560: why anonymous writes succeed
The other half of the chain is a separate defect in 389 Directory Server, tracked as CVE-2026-76560 and scored by Red Hat at 7.5. The directory-server rule type meant to enforce "only the authenticated owner of this entry" compares the client's name against a stored value as plain text. If a client has not logged in, its name is empty; that empty name will match an empty stored owner value. An anonymous client can therefore create an entry whose ownership fields are left blank, pass the ownership check by being "nobody," and write a Kerberos identity and password alongside the token entry.
Red Hat reproduced the directory-server defect on a plain 389-ds build with no FreeIPA components installed, and a control test using a non-empty owner value was correctly refused, which Red Hat says places the fault in the access-control engine rather than in FreeIPA itself. Red Hat also notes that Red Hat Directory Server ships no rule of that exact shape by default — the danger arises because FreeIPA does ship such an ACI by default, allowing the chain to work against an untouched installation.
Audit-ready is a season. It shouldn't be.
Evidence in spreadsheets, controls drifting between audits, frameworks multiplying on flat headcount. Nubivance runs continuous compliance on Rapid7 Cyber GRC - SOC 2, HIPAA, ISO 27001, PCI, CMMC.
End the scrambleCVE-2026-79678: the idp-add eval() issue and container exposures
Red Hat disclosed a second, unrelated FreeIPA flaw as CVE-2026-79678 with a score of 8.1. The idp-add command passes two caller-supplied values — an organization name and a base URL — into a Python eval() call. Crucially, that eval() runs before the permission check intended to limit the command to identity-provider administrators, so any account on the server can reach it. Red Hat says the call is limited by a pattern that forbids brackets, and therefore "no code execution is possible."
Even without code execution, the idp-add defect allows an attacker to read the server process's environment variables one at a time by observing errors, and to exhaust the server's memory with a short arithmetic expression. How impactful that is depends on installation method: Red Hat says on typical package installs the process environment holds only documented paths and settings, while container installs differ. 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 in the running process environment after setup finishes. Red Hat says a fixed package is required to address this issue.
What administrators can do now
- Apply FreeIPA 4.13.4 or later to pick up the FreeIPA-side fix where available.
- Until fixed packages are in place, Red Hat recommends restricting access to the LDAP service (typically ports 389 and 636) to trusted hosts via firewall rules or network segmentation.
- Turning off anonymous LDAP binds blocks the particular FreeIPA–389-ds attack path, but administrators must first confirm that no other deployment component requires anonymous binds.
- For the idp-add flaw, Red Hat says no configuration toggles will block an ordinary authenticated account from reaching the vulnerable code; a package update is required. Container operators should verify that first-boot passwords are no longer present in the running process environment.
Red Hat also notes that the fixes have been released across "three different places at three different times," so administrators must check each component relevant to their deployment. As of 8 September, the published bug record showed no advisory for plain Red Hat Enterprise Linux 9 in that list of fourteen updates.
How this lands for technologists, container operators, and enterprise administrators
- Technologists and security teams should prioritize confirming FreeIPA package versions (the project fixed its side in 4.13.4) and monitor for corresponding 389-ds updates; Red Hat validated the chain against a stock FreeIPA container image running 4.13.1 and verified results with administrator-only commands.
- Container operators must inspect running process environments. Because the official server image may accept Directory Manager and administrator passwords as environment variables at first boot, those secrets could be exposed if left in the environment after setup.
- Enterprise administrators should implement the temporary network mitigations Red Hat recommends (restrict LDAP access; consider disabling anonymous binds) while tracking the staggered package updates and confirming that fixes remove the attack surface in their specific configuration.
Two practical questions remain in the published material: whether a 389-ds update alone stops the FreeIPA attack on servers whose ipa packages are still outdated, and whether applying fixes removes identities an attacker may have created before patches were installed. Neither of those questions — nor detection rules or indicators — appear in the advisories or bug reports Red Hat and the FreeIPA project published.
