GHSA-9237-rg5p-rhfw: 
JavaScript vulnerability analysis and mitigation

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.