Freeipa vulnerabilities
We track 6 vulnerabilities in Freeipa products. 6 are rated high or critical, and none are known to be exploited. The most recent was published on August 20, 2026.
Latest Freeipa vulnerabilities
- 7.5 High severity
Red Hat Enterprise Linux 10: Allocation of Resources Without Limits or Throttling
A flaw was found in FreeIPA. A remote, unauthenticated attacker can exploit a vulnerability in the `/ipa/i18n_messages` endpoint by sending an arbitrarily large request body. This can cause the service to consume excessive memory, leading to memory exhaustion,
- 7.5 High severity
Red Hat Enterprise Linux 10: Allocation of Resources Without Limits or Throttling
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 bodie
- 8.7 High severity
Red Hat Enterprise Linux 10: Use of Incorrectly-Resolved Name or Reference
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
- 8.1 High severity
Red Hat Enterprise Linux 10: Incorrect Privilege Assignment
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 imperson
- 8.2 High severity
Red Hat Enterprise Linux 10: Incorrect Authorization
A flaw was found in FreeIPA. The trust-fetch-domains command is gated by a read-only permission on the trust object rather than a trust-administration permission, allowing an authenticated, non-privileged IPA user to trigger a privileged Active Directory trust
- 8.8 High severity
Red Hat Enterprise Linux 8: Incorrect Authorization
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 check_allowed_to_delega