{"id":"GHSA-9237-rg5p-rhfw","aliases":[],"status":"published","title":"@saltcorn/data: Tenant user role is used for tenant creation role check","description":"## Summary\n\nWhen 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 \u003e _sc_tenants`), rather than in the tenant's own `_sc_tenants` table.\n\nIf the same logic applies to other routes, a tenant admin effectively gains admin rights on the root domain.\n\n## PoC\n\nA tenant-created subtenant appears under the Saltcorn public schema instead of the tenant's own schema.\n\n- 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.\n- 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.\n\n## Impact\n\nTenant 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.","severity":{"version":"4.0","score":8.7,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N","level":"high","from":"ghsa"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-863"],"published":"2026-04-22T14:31:34Z","modified":"2026-04-22T14:58:32Z","fixes":[{"ecosystem":"npm","package":"@saltcorn/data","fixed_in":["1.4.4","1.5.2","1.6.0-beta.2"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"npm","package":"@saltcorn/data","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.4.4"}]}]},{"source":"ghsa","ecosystem":"npm","package":"@saltcorn/data","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"1.5.0-beta.0"},{"fixed":"1.5.2"}]}]},{"source":"ghsa","ecosystem":"npm","package":"@saltcorn/data","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"1.6.0-alpha.0"},{"fixed":"1.6.0-beta.2"}]}]},{"source":"osv","ecosystem":"npm","package":"@saltcorn/data","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"1.4.4"}]}]},{"source":"osv","ecosystem":"npm","package":"@saltcorn/data","ranges":[{"type":"SEMVER","events":[{"introduced":"1.5.0-beta.0"},{"fixed":"1.5.2"}]}]},{"source":"osv","ecosystem":"npm","package":"@saltcorn/data","ranges":[{"type":"SEMVER","events":[{"introduced":"1.6.0-alpha.0"},{"fixed":"1.6.0-beta.2"}]}]}],"references":[{"url":"https://github.com/saltcorn/saltcorn/security/advisories/GHSA-9237-rg5p-rhfw","tags":["web"]},{"url":"https://github.com/advisories/GHSA-9237-rg5p-rhfw"},{"url":"https://github.com/saltcorn/saltcorn","tags":["package"]}],"sources":{"ghsa":[{"id":"GHSA-9237-rg5p-rhfw","title":"@saltcorn/data: Tenant user role is used for tenant creation role check","description":"## Summary\n\nWhen 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 \u003e _sc_tenants`), rather than in the tenant's own `_sc_tenants` table.\n\nIf the same logic applies to other routes, a tenant admin effectively gains admin rights on the root domain.\n\n## PoC\n\nA tenant-created subtenant appears under the Saltcorn public schema instead of the tenant's own schema.\n\n- 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.\n- 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.\n\n## Impact\n\nTenant 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.","status":"published","published":"2026-04-22T14:31:34Z","modified":"2026-04-22T14:31:35Z","cvss":[{"version":"4.0","score":8.7,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N","level":"high"}],"cwes":["CWE-863"],"updated_at":"2026-11-02T14:39:55.105822Z"}],"osv":[{"id":"GHSA-9237-rg5p-rhfw","title":"@saltcorn/data: Tenant user role is used for tenant creation role check","description":"## Summary\n\nWhen 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 \u003e _sc_tenants`), rather than in the tenant's own `_sc_tenants` table.\n\nIf the same logic applies to other routes, a tenant admin effectively gains admin rights on the root domain.\n\n## PoC\n\nA tenant-created subtenant appears under the Saltcorn public schema instead of the tenant's own schema.\n\n- 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.\n- 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.\n\n## Impact\n\nTenant 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.","status":"published","published":"2026-04-22T14:31:34Z","modified":"2026-04-22T14:58:32.498203Z","cvss":[{"version":"4.0","score":8.7,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N","level":"high"}],"cwes":["CWE-863"],"updated_at":"2026-11-02T15:46:43.123867Z"}]}}