Hhh0710

An authorization flaw exists in the `checkPermissionsForCreateOrUpdate()` function within the `Multitenancy` class. In licensed multi-tenant deployments where multiple applications share a non-default connection URI domain and use separate `api keys`, an attacker with a valid API key for one application can update the parent connection URI domain. This occurs because the system fails to require the source application and tenant to be public when checking the domain during create or update operations. Consequently, an attacker can replace the parent key and sibling application keys, modify sibling users, hijack sessions, and establish persistence via sibling dashboard users. Additionally, omitting the optional identifier in v2 create or update handlers allows an attacker to target the base tenant, bypassing permission checks and enterprise-feature gates to modify `firstFactors`, required secondary factors, and recipe-enabled flags, which compromises login integrity and availability.

In multi-tenant deployments using WebAuthn with a shared user pool, the server fails to constrain lookups to the requested tenant and does not verify tenant membership during sign-in. This allows a user with a valid passkey in one tenant to authenticate into another tenant within the same application, even without membership in the target tenant. The issue involves the `loadOptionsById Transaction()` and `getUserInfoByCredentialId Transaction()` functions, as well as the `WebAuthN.signIn` method.