FreeIPA Just Lost Its Front Door. Anonymous LDAP Can Become Admin
- The Mess: A new FreeIPA vulnerability chain lets an unauthenticated LDAP client create a Kerberos identity it controls and place that identity in the administrators group.
- The Damage: An attacker who reaches the vulnerable LDAP service can turn zero credentials into persistent administrative access across a Linux identity domain.
- The Fix: Upgrade FreeIPA to 4.13.4 or the appropriate vendor-fixed package and patch the underlying 389 Directory Server immediately.
FreeIPA is supposed to be the system deciding who gets to log in.
This week, that trust boundary got punched straight through.
The main vulnerability is CVE-2026-76578, rated CVSS 9.8 by Red Hat. The flaw allows an unauthenticated LDAP client to manipulate FreeIPA’s identity-management logic and create a Kerberos identity of its choosing. The resulting identity can end up in the admins group.
There is no password to steal.
There is no legitimate account to compromise.
The attacker starts outside.
The Attack Starts With Anonymous LDAP
FreeIPA uses LDAP as the directory underneath its identity-management stack.
One of the affected access-control rules allowed users to manage their own OTP token. The problem was that the relevant ACI did not properly require authentication.
That turns an operation intended for an existing identity into something an anonymous LDAP client can abuse.
But there is another problem.
The LDAP server itself has a separate flaw.
CVE-2026-76560 Breaks the Second Barrier
The second vulnerability, CVE-2026-76560, affects 389 Directory Server.
It involves the SELFDN ACI bind-rule evaluator incorrectly matching an anonymous LDAP client. Red Hat rates this vulnerability CVSS 7.5.
On its own, that might look like a serious but contained LDAP authorization problem.
Combined with CVE-2026-76578, it becomes much worse.
The two bugs effectively remove two separate assumptions:
“You must authenticate before manipulating your identity.”
and
“Anonymous LDAP cannot satisfy this identity-based access rule.”
Break both, and the attacker gets a path into the identity system itself.
The Result Is Not Just LDAP Access
This is where the FreeIPA flaw becomes nasty.
The attacker does not merely read directory data.
The attack can create a Kerberos principal controlled by the attacker and place it into the administrators group.
That turns an anonymous network request into an identity with legitimate-looking credentials.
Once the attacker has that identity, the normal FreeIPA authentication machinery starts working for them.
That is much harder to detect than a noisy exploit that simply crashes a daemon.
The attacker isn’t necessarily running around with a giant “I AM HACKING FREEIPA” flag.
They can become an identity the system recognizes.
Red Hat Tested the Chain
This is not just a theoretical combination of two CVEs.
Red Hat says it reproduced the attack chain twice on a default installation, including a test performed on a system where the attacker had no prior access.
That matters.
FreeIPA installations often become the authentication backbone for Linux environments.
They can manage users, hosts, Kerberos authentication, sudo policies and other identity-related controls. FreeIPA can also participate in Active Directory trust configurations.
Compromise the identity layer and the attacker doesn’t necessarily need to exploit every server individually.
The identity system can become the force multiplier.
The Fix Is Already Out
The FreeIPA project fixed its side of the problem in version 4.13.4.
Package repositories have already started shipping the update. For example, the FreeIPA 4.13.4 package update explicitly lists CVE-2026-76578 among the fixes.
The underlying 389 Directory Server component also needs to be updated for CVE-2026-76560.
Patching only FreeIPA while leaving the vulnerable directory layer behind is not the kind of half-fix defenders should trust.
This is a chain.
Patch the chain.
Check More Than the Version Number
If a FreeIPA server was exposed while vulnerable, patching should not be the end of the investigation.
Administrators should review:
- newly created FreeIPA users;
- unexpected Kerberos principals;
- membership changes in privileged groups;
- suspicious OTP objects;
- LDAP authentication activity;
- Kerberos authentication logs;
- changes to sudo and host-access policies.
The particularly interesting indicator is an identity that should not exist but now looks completely legitimate.
That’s what makes identity-layer compromise dangerous.
The attacker isn’t necessarily bypassing authentication forever.
They may have simply created authentication for themselves.
Bugstoday Opinion
This is the kind of vulnerability that makes “we have LDAP behind the firewall” a weak argument.
The important question isn’t whether LDAP is supposed to be trusted.
It’s what happens when an anonymous request reaches it.
FreeIPA is an identity authority. Once an attacker can manufacture an identity inside that authority and attach administrative privileges to it, the compromise becomes much bigger than a single vulnerable endpoint.
The scary part isn’t the 9.8 score.
It’s the fact that the attacker can go from:
anonymous → identity → Kerberos → administrator.
No stolen password required.
Today’s Bugs. Tomorrow’s Breaches.
Technical Sources
- Red Hat — CVE-2026-76578
- Red Hat / 389 Directory Server — CVE-2026-76560
- FreeIPA — 4.13.4 security release
- NVD — CVE-2026-76578
- The Hacker News — FreeIPA anonymous LDAP attack-chain analysis
