FreeIPA Bug Lets Unknown Users Mint Themselves Admin Accounts
A two-flaw chain in Red Hat's identity system lets an anonymous client create a Kerberos account and land in the administrators group with no credentials required.
Key points
- Red Hat disclosed a flaw chain in FreeIPA that lets a client with no prior login create a Kerberos identity and join the administrators group.
- The attack requires a second flaw in the 389 Directory Server database that FreeIPA relies on to store user accounts.
- FreeIPA controls who can log in across Linux networks in enterprises, universities and government systems.
- Administrators should patch both components once Red Hat's fixes reach their distribution.
- No public proof-of-concept exploit has been tied to in-the-wild abuse at the time of writing.
Red Hat has warned of a flaw in FreeIPA, the software many Linux shops use to manage who is allowed to log in where, that lets a stranger walk in and hand themselves the keys. No credentials. No prior account. Just a request and a group membership that shouldn't be theirs.
The bug lets a client that has never authenticated create a Kerberos identity of its own choosing inside the directory. Kerberos is the ticket system Linux networks use to vouch for a user once they log in. Because the attacker picks the name, they can plant themselves straight into the administrators group, giving full control of the identity system that decides who gets into every server behind it.
What is FreeIPA and why does this matter?
FreeIPA is the central sign-on system for many Linux environments: the bouncer's clipboard for a whole company's servers, holding the list of users, their passwords and group memberships, and the rules about which machines they can touch.
Under the hood, FreeIPA keeps all of that in a database called 389 Directory Server, accessed via LDAP, a decades-old protocol for looking up users and groups. If an attacker can rewrite that clipboard, they can log in as anyone the system trusts.
That's what this chain allows. It's a pattern we've seen before: our story on a Keycloak flaw that handed full account takeover with no credentials, published on 24 August, shows how often unauthenticated identity attacks are landing in open-source login infrastructure right now.
How does the attack work?
Two flaws are needed, according to Red Hat's advisory as reported by The Hacker News.
The first sits in FreeIPA itself, letting an unauthenticated client send a request to create a Kerberos principal (the technical name for a Kerberos identity) using any name it likes. The second sits in the 389 Directory Server that FreeIPA writes to. Together they let the attacker place that fresh identity into a privileged group, including the administrators group that controls the whole directory.
The account is then reusable. The attacker can return and log in as an administrator at will.
Who is affected?
| Component | Role | Action |
|---|---|---|
| FreeIPA | Identity and access management server | Apply Red Hat fix when released |
| 389 Directory Server | LDAP database behind FreeIPA | Apply Red Hat fix when released |
| Kerberos principals store | Where the rogue account lands | Audit for unexpected admin accounts |
Anyone running FreeIPA on Red Hat Enterprise Linux, CentOS Stream or Fedora, or a downstream rebuild, should treat this as urgent. Desktop users and the general public aren't directly at risk. The exposure sits on the servers their IT teams manage.
What should administrators do now?
Watch Red Hat's security advisories for the FreeIPA and 389-ds-base packages and patch both. Fixing only one side of the chain isn't enough.
While waiting, restrict network access to the FreeIPA server so only trusted management networks can reach the Kerberos and LDAP ports. Review the administrators group for accounts you don't recognise, especially recent ones.
If you find one, treat the directory as compromised and rotate credentials from the top down. Our guide to least-privilege access on file servers is worth a read while you're auditing group memberships.
The deeper concern here isn't the patch cycle: it's that unauthenticated identity flaws keep appearing in the infrastructure that Linux shops chose precisely because they wanted an alternative to Active Directory. That trust is now costing them attention.
