GHSA-9237-rg5p-rhfw

## Summary When a tenant admin is logged out of the root domain (e.g., saltcorn.com) but logged in to their own tenant space as admin, they can simply append `/tenant/create` to their tenant URL. The system reads the role from the tenant context (admin), and a new tenant is created on the **root domain** (in `PUBLIC SCHEMA > _sc_tenants`), rather than in the tenant's own `_sc_tenants` table. If the same logic applies to other routes, a tenant admin effectively gains admin rights on the root domain. ## PoC A tenant-created subtenant appears under the Saltcorn public schema instead of the tenant's own schema. - Even when `role_id=1` is required for tenant creation on saltcorn.com (only admin can create tenants), existing tenant admins can still create new tenants because their local `role_id:1` is evaluated against the root domain. - Even when `role_to_create_tenant` is set to `0` in the tenant's `_sc_config` schema, or removed entirely, the tenant admin can still create sub-tenants on the root domain — suggesting `role_to_create_tenant` is not being read at all. ## Impact Tenant admins gain unauthorized admin-level access to the root domain. Any authenticated tenant admin can perform privileged operations (e.g., creating tenants) on the root domain by exploiting the role context mismatch.