CVE-2026-76578 is a Red Hat-rated Critical FreeIPA vulnerability that can contribute to a remote, unauthenticated path to genuine administrator-group privileges. Red Hat says it reproduced full administrative compromise on a stock FreeIPA installation from a client with no prior access.
The most important qualification is that the demonstrated chain does not rely on CVE-2026-76578 alone. Red Hat says it also depends on CVE-2026-76560, a related 389 Directory Server access-control flaw. Administrators therefore need to verify the security state of both the FreeIPA and directory-server components rather than treating this as a single-package version check.
What CVE-2026-76578 allows
Red Hat describes a flaw involving FreeIPA access-control rules for self-managed OTP token operations. When combined with the companion 389 Directory Server ACI-evaluation issue, an unauthenticated LDAP client with network reachability can create an attacker-controlled Kerberos principal and place that principal into FreeIPA’s administrators group.
This is not merely a cosmetic group-membership issue. Red Hat says it independently demonstrated genuine administrator privileges and the ability to perform administrator-only directory and identity-management operations.
Why CVE-2026-76560 matters
CVE-2026-76560 affects 389 Directory Server’s evaluation of certain SELFDN and USERDN access-control rules. In the relevant condition, an anonymous client’s empty bind distinguished name can incorrectly match an empty stored attribute. That behavior becomes a necessary primitive in the FreeIPA administrator-compromise chain documented by Red Hat.
For that reason, an article or scanner result that considers only CVE-2026-76578 can give an incomplete operational picture. The administrator should verify whether both relevant components have received the applicable security fixes from the vendor or distribution that supplied them.
Does the attack require credentials?
Red Hat’s reproduced attack required no credentials, no prior authenticated access and no user interaction. The attacker does, however, need network access to the LDAP service. That makes LDAP exposure a material part of the risk assessment.
A FreeIPA or Red Hat IdM server whose LDAP service is reachable from untrusted networks should therefore be treated differently from an otherwise identical system whose LDAP access is tightly restricted to trusted hosts or management networks.
Does the earlier CVE-2026-13097 fix stop this?
No. Red Hat says the earlier CVE-2026-13097 remediation blocks a specific canonical-principal naming collision that could be used to impersonate the literal admin identity. It does not eliminate the underlying unauthenticated write path exploited by the newer chain.
With CVE-2026-76578 and the companion directory-server behavior still present, an attacker can instead create another principal under attacker control and add it to the administrators group. Administrators should therefore not use the presence of the earlier fix as evidence that this newer exposure is closed.
Which FreeIPA version contains the upstream fix?
The FreeIPA project documents security hardening for CVE-2026-76578 in FreeIPA 4.13.4. That upstream version is useful as a reference point, but it is not a universal package instruction for every operating system.
Red Hat and other Linux vendors can backport security fixes into older-looking package versions. A RHEL or other distribution user should therefore verify the current advisory and fixed package supplied by that distribution rather than deciding vulnerability state from the upstream FreeIPA version string alone.
Package status differs by distribution
The reviewed distribution evidence already shows that one answer does not fit every platform. Amazon Linux, for example, records Amazon Linux 2 as fixed through its security advisory while Amazon Linux 2023 is listed as not affected. Ubuntu, Fedora and other ecosystems maintain their own package and vulnerability states.
This means the correct question is not simply, “Is my FreeIPA older than 4.13.4?” It is, “Has the vendor that supplied my FreeIPA and 389 Directory Server packages shipped the relevant fixes for my supported release?”
What administrators should check now
Record the installed FreeIPA or Red Hat IdM package state and the associated 389 Directory Server package rather than checking only one CVE or one version string.
Check the current advisory or package status from Red Hat or the Linux distribution that supplied the software. Do not assume that a backported fix must carry the same version number as upstream FreeIPA 4.13.4.
Determine whether TCP ports 389 or 636 are reachable from untrusted networks or systems that do not need directory access.
Red Hat recommends limiting LDAP access to trusted hosts or network segments while remediation is incomplete.
Red Hat says disabling anonymous LDAP binds blocks this specific attack path, but administrators should first verify that required services or workflows do not depend on anonymous access.
Confirm remediation for the affected FreeIPA behavior and the related 389 Directory Server issue rather than assuming that fixing only one component closes the complete demonstrated chain.
Is CVE-2026-76578 actively exploited?
TPS did not verify active exploitation in the wild from the reviewed evidence. Red Hat’s successful reproduction establishes exploitability and severity, but a vendor laboratory reproduction is not the same as evidence of malicious exploitation against production systems.
No current CISA Known Exploited Vulnerabilities listing was established during the completed review. That state can change and should be updated on this same URL if CISA, Red Hat or another controlling source later confirms exploitation.
How to think about a possible prior compromise
The current primary evidence is strong enough to explain exposure and remediation, but it does not provide a complete campaign-specific forensic playbook for identifying already-compromised deployments. Administrators who have reason to suspect exploitation should follow current vendor and organizational incident-response procedures rather than assuming that installing a package update alone establishes that the environment was never compromised.
If credible exploitation evidence later produces a distinct forensic task, such as identifying attacker-created Kerberos principals or unauthorized administrator-group changes, that could justify a separate post-compromise investigation guide. For now, that job remains outside the confirmed scope of this article.
What happens next
The most important updates will be fixed-package and errata changes from Red Hat and downstream distributions, revised 389 Directory Server guidance, evidence of real-world exploitation, or escalation through CISA or CERT channels. Those developments should update this same canonical because they change the answer to the same administrator question: whether the deployment remains exposed and what remediation is required.