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 `kinit_password()` 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 `fetch_domains()`/`discover_trust_instance()`. This fabricated data is written directly into the IPA LDAP directory as authoritative trust/ID-range topology by `trust.add_new_domains_from_trust()`. 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.