Skip to content
Patch Next
Sign inAdd to your agent

← Actionable
High, CVSS 8.7amended

@saltcorn/data: Tenant user role is used for tenant creation role check

GHSA-9237-rg5p-rhfw

What to do

Vendor fix available. Upgrade each affected package to the fixed version on its release line (@saltcorn/data 1.6.0-beta.2, 1.5.2, 1.4.4), redeploy, then verify what is actually installed.

This page has no inventory attached, so it cannot say whether you are affected. A vendor fix is not proof that your deployment is fixed.

Add to your agent

Affected packages

  • npm @saltcorn/data

    Affected
    < 1.4.4>= 1.5.0-beta.0, < 1.5.2>= 1.6.0-alpha.0, < 1.6.0-beta.2
    Fixed in
    1.5.2, 1.6.0-beta.2, 1.4.4

Sources

Severity and exploitation
Exploitation
No confirmed exploitation recorded. Patch Next marks exploitation only from CISA KEV.
CVSS 4.0
8.7 · 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 · score source
EPSS
No dated EPSS signal available.
Source description

As published by the source; long descriptions are shortened.

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 sctenants), rather than in the tenant's own sctenants 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 roleid=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 roleid:1 is evaluated against the root domain. - Even when roletocreatetenant is set to 0 in the tenant's scconfig schema, or removed entirely, the tenant admin can still create sub-tenants on the root domain — suggesting…

Dates and revisions
Published by the source
Last modified by the source
Source last checked
  1. Revision 3 · amended ·

    Amended from ghsa record GHSA-9237-rg5p-rhfw

  2. Revision 2 · amended ·

    Reviewed OSV alias/range/CVSS4 correction; package source scopes and original publication preserved. No customer finding resolved.

  3. Revision 1 · created ·

    Published from osv record GHSA-9237-rg5p-rhfw

Agent brief

Preview the exact text before you copy it. Commands are read-only suggestions; review them before running anything.

# Patch Next advisory brief: GHSA-9237-rg5p-rhfw

Advisory: @saltcorn/data: Tenant user role is used for tenant creation role check
IDs: GHSA-9237-rg5p-rhfw
Record: https://patchnext.com/advisories/ghsa-9237-rg5p-rhfw (revision 3, source checked 26 Oct 2026, 12:48 UTC)
Inventory: none attached. This brief comes from a public page and does not say whether any deployment is affected.
Severity: High (CVSS 8.7)
Exploitation: no confirmed exploitation recorded. Patch Next confirms exploitation only from CISA KEV.
Vendor response: Vendor fix available; fixed versions by package: @saltcorn/data 1.6.0-beta.2, 1.5.2, 1.4.4. A vendor fix does not mean a deployment is fixed.

## Affected components
- npm @saltcorn/data: affected < 1.4.4; >= 1.5.0-beta.0, < 1.5.2; >= 1.6.0-alpha.0, < 1.6.0-beta.2; fixed in 1.5.2, 1.6.0-beta.2, 1.4.4

## Suggested inspection (read-only)
- `npm ls @saltcorn/data --all`: lists every installed copy and version, including transitive ones. Run in the project root after `npm ci`.

## Supported action
Upgrade each affected component to a fixed version on its release line. For a transitive dependency, upgrade the parent package or add an override or constraint, then regenerate the lockfile. Redeploy every environment that ran an affected version.

## Required regression checks
- Run the test suite and a production build.
- Exercise the features that depend on @saltcorn/data.
- Repeat the inspection and confirm that only fixed versions remain installed.

## Rollback considerations
- Keep the previous lockfile and deployment artifact. Rolling back reinstates the vulnerable version, so apply any documented mitigation while you fix forward.

## Unresolved questions
- Which deployments run an affected version?
- Exploitation status can change. Check again before lowering the priority.
- Mark the work resolved only after the fixed version is verified in production.

## Sources
- Verified: https://osv.dev/vulnerability/GHSA-9237-rg5p-rhfw (OSV record GHSA-9237-rg5p-rhfw lists affected ranges: npm @saltcorn/data >=0 =1.5.0-beta.0 =1.6.0-alpha.0 <1.6.0-beta.2 (fixed))
- Verified: https://github.com/advisories/GHSA-9237-rg5p-rhfw (GitHub-reviewed advisory GHSA-9237-rg5p-rhfw lists affected ranges: npm @saltcorn/data >=0 =1.5.0-beta.0 =1.6.0-alpha.0 <1.6.0-beta.2)

Commands are suggestions: review each one before running it.

Loading voting…