A FreeIPA flaw chain let an anonymous client write itself a reusable administrator credential

Gia Bui and researchers at Calif, working with Anthropic, reported a flaw chain in FreeIPA. CVE-2026-76578 (CVSS 9.8) is an access control rule that lets users manage one-time-password tokens without authenticating first, and fails to restrict what else can be written alongside a token. CVE-2026-76560 (CVSS 7.5) in 389 Directory Server compares client names as plain text during an ownership check, so an unauthenticated client presenting an empty name matches an empty stored value and passes. Chained: an anonymous client creates a token entry with ownership left blank, satisfies the ownership check by being nobody, and writes a Kerberos identity and password next to it. A third flaw, CVE-2026-79678 (CVSS 8.1), was disclosed alongside. FreeIPA 4.13.4 fixes both FreeIPA issues; Red Hat issued Directory Server advisories on September 8, 2026, with some RHEL package statuses still open at disclosure.

Why it matters

FreeIPA is the directory, the Kerberos KDC, and frequently the certificate authority for Linux estates, which puts this in the same tier as the Active Directory techniques we covered in Issue 9. Writing a Kerberos identity into the directory is not privilege escalation toward the goal; it is the goal.

The mechanism deserves a moment because it is a beautiful and entirely typical authorization bug. Neither component is broken on its own terms. FreeIPA assumes the directory enforces ownership. The directory enforces ownership by string comparison, and an anonymous bind has no name, and empty equals empty. The vulnerability lives in the gap between two correct-looking implementations, which is where authorization failures usually live and why they survive code review on both sides.

Patch to FreeIPA 4.13.4 and track the Directory Server advisories for your distribution. Then hunt, because this leaves directory artifacts rather than host artifacts: look for OTP token entries with blank ownership fields, Kerberos principals created outside your provisioning process, and any principal whose creation timestamp has no corresponding ticket in your IdM audit trail. Restrict anonymous binds, and treat the KDC's write paths as an inventory you maintain rather than a default you inherit.

Source: The Hacker News