An Anonymous LDAP Bind Can Mint a FreeIPA Admin: Inside the CVE-2026-76578 Chain

Who owns a directory entry that has nobody in its owner field? On an unpatched FreeIPA server, the answer is whoever asks for it first.

Red Hat published three FreeIPA advisories on September 8. The one to read is CVE-2026-76578, scored 9.8 with the vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. An LDAP client that has never authenticated can create a one-time-password token entry, leave the ownership attribute empty, and write a Kerberos principal and password into the same operation. The principal ends up in the admins group. Red Hat reproduced the chain on default installations with no prior access and classified it as CWE-306, missing authentication for a critical function. Gia Bui of Calif.io reported it.

This one is yours if you run FreeIPA or Red Hat Identity Management below 4.13.4 and ports 389 or 636 answer anything you do not fully control: a flat office network, a VLAN shared with contractor laptops, a cloud subnet with a security group somebody widened in 2023. Linux-first shops, universities, research groups and the managed service providers who run their fleets are the population here. If your identity stack is Active Directory and Entra ID only, close this tab and go work your Patch Tuesday queue instead; the September batch has two exploited Windows privilege-escalation bugs waiting for you.

The part that changes your response plan: an attacker who used this before you patched walks away with a working administrator account and its Kerberos credential. That account is a legitimate directory object. Upgrading the package does not delete it. Patching closes the door and leaves whoever came through it standing in the room.

How an empty bind DN passes an ownership check

Two separate design decisions have to meet for this to work, which is why it survived years of review.

FreeIPA ships an access control instruction so a user can manage their own OTP token. The rule does not require the client to have authenticated, and it does not constrain what else may be written alongside the token. On its own that is a curiosity, because an ownership check is supposed to stop an anonymous client from claiming a token that is not theirs.

That ownership check is the second half. 389 Directory Server evaluates bind rules of the form userattr="attribute#SELFDN" by comparing the client's bind DN against a stored attribute value as plain text. An anonymous client's bind DN is the empty string. When the stored attribute is also empty, the two match and the client passes the test by being nobody. Red Hat tracks that behaviour as CVE-2026-76560 at 7.5, with an integrity-only impact vector of AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N.

Read alone, the directory-server bug looks like a hardening note. Red Hat's own text calls it dangerous only in combination with FreeIPA's default rules. The FreeIPA ACI is what converts an evaluator quirk into an unauthenticated path to admins: create the token with the owner field blank, satisfy the SELFDN rule against that blank value, and attach krbPrincipalName and a password in the same write. The result is a normal-looking account you can authenticate as tomorrow.

The third advisory, and why containers get the worse end of it

CVE-2026-79678 is a different shape. The idp-add command passes insufficiently validated --organization and --base-url input into a constrained Python eval() call before it enforces permissions. Red Hat rates it 8.1 with PR:L, so it needs a low-privileged account first.

A regex blocks parentheses, which blocks arbitrary code execution. What remains is still useful to an attacker: dict-unpacking and boolean-exception oracles read environment variables one at a time, and a right-associative exponentiation payload exhausts memory on the server. Red Hat classifies it as CWE-95, eval injection, and Calif.io reported this one too.

Your exposure depends on how the server was installed. An RPM deployment leaks ordinary filesystem paths through that oracle. A containerised deployment can leak whatever the process environment still holds, and initial boot passwords are the usual resident. Check the environment of your running IdM containers before you decide this third CVE is a low priority for you.

Patch, then work out whether anyone already used it

The upstream fix for both FreeIPA CVEs is 4.13.4. The 389 Directory Server side ships through distribution errata, including RHSA-2026:64785 for RHEL 10; other streams were still listed as under investigation when the advisories went out, so confirm the state of the stream you actually run rather than assuming your rebuild has caught up.

Then hunt. These five checks take about ten minutes on a single server and answer the question the patch cannot.

# 1. What is actually installed on this server?
rpm -q ipa-server 389-ds-base

# 2. Does an unauthenticated client still get an answer?
ldapsearch -x -H ldap://idm01.example.com -b "" -s base "objectclass=*" \
  namingContexts supportedSASLMechanisms

# 3. Who is in the admins group right now?
ipa group-show admins --all --raw

# 4. OTP token entries with no owner - the write primitive in CVE-2026-76578
ldapsearch -x -D "cn=Directory Manager" -W -H ldaps://idm01.example.com \
  -b "cn=otp,dc=example,dc=com" "(!(ipatokenOwner=*))" dn createTimestamp

# 5. Anonymous binds, and the writes that followed them
grep 'BIND dn="" ' /var/log/dirsrv/slapd-EXAMPLE-COM/access | tail -50
grep 'ADD dn=' /var/log/dirsrv/slapd-EXAMPLE-COM/access | tail -50

What a compromised server looks like

• A member of admins that nobody on your team can account for, especially one whose name imitates a service account.
• An OTP token object under cn=otp with an empty ipatokenOwner and a creation timestamp you cannot tie to an enrolment.
• An anonymous BIND dn="" in the directory access log followed within the same connection by an ADD operation.
• A Kerberos principal created outside your change window, or outside working hours in the timezone your admins actually keep.

Run the checks on every server in the topology. FreeIPA replicates, so an entry written to one replica reaches the others in seconds, and the server that took the anonymous connection is not necessarily the one you patched first. ipa-replica-manage list prints the full set. The same applies to the fix: a realm with one unpatched replica still has an open front door, and enrolled clients will follow whichever server answers.

If any of those land, run your identity-compromise process rather than your patching process. Disable the account, rotate the credentials it could reach, and pull the access log for the full connection rather than the single line that caught your eye. A directory takeover that ends in admins gives an attacker every host enrolled in the realm, because that is the point of enrolling them.

If you cannot patch today, take LDAP off the open network

Red Hat's own mitigation text for CVE-2026-76578 gives two options, and both are worth doing regardless of how fast you patch.

The first is network. Restrict access to the LDAP service, typically ports 389 and 636, to trusted hosts using firewall rules or segmentation. A FreeIPA server in a small environment usually answers from the whole office subnet, because that was the shortest path to a working install and nobody revisited it after the clients enrolled.

The second is the anonymous-access switch in 389 Directory Server. Red Hat recommends the value rootdse rather than off, because off also stops external clients from reading the server configuration:

ldapmodify -x -D "cn=Directory Manager" -W -H ldapi://%2fvar%2frun%2fslapd-EXAMPLE-COM.socket <<'EOF'
dn: cn=config
changetype: modify
replace: nsslapd-allow-anonymous-access
nsslapd-allow-anonymous-access: rootdse
EOF

systemctl restart dirsrv@EXAMPLE-COM

# Confirm it took
ldapsearch -x -D "cn=Directory Manager" -W -b "cn=config" -s base \
  nsslapd-allow-anonymous-access

Confirm first that nothing in your estate depends on anonymous binds. Red Hat says the same in the advisory, and the warning is real: some older client tooling and a few monitoring agents read the directory without credentials, and they stop working the moment you flip this. Test it on one replica before you push it to all of them.

One more thing before you close the ticket: the directory access log is the only place this attack leaves a mark, and the defaults do not keep it long. On a busy server, nsslapd-accesslog-maxlogsperdir and nsslapd-accesslog-logexpirationtime can rotate the evidence away inside a few days, and log buffering means the last minutes may not be on disk when you go looking. Forward the access log to whatever you use for retention now, so the next directory question you get has an answer older than this week.

Name every member of the admins group before Friday

Do three things this week, in this order. Upgrade FreeIPA to 4.13.4 and apply the 389 Directory Server errata for your stream. Put the directory ports behind the same firewall rules you would put in front of a domain controller, because the server does the same job. Then list the members of admins and every OTP token without an owner, and be able to name each one.

Most small teams have written the hardening plan for their Windows domain and never wrote one for the Linux directory sitting next to it. If yours is in that state, we assess identity infrastructure - Active Directory, Entra ID, and FreeIPA or IdM deployments - for the misconfigurations attackers actually use, and hand back a prioritised list rather than a scan report.