GHSA-9237-RG5P-RHFW

Vulnerability from github – Published: 2026-04-22 14:31 – Updated: 2026-04-22 14:31
VLAI
Summary
@saltcorn/data: Tenant user role is used for tenant creation role check
Details

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.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@saltcorn/data"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@saltcorn/data"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.5.0-beta.0"
            },
            {
              "fixed": "1.5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@saltcorn/data"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.6.0-alpha.0"
            },
            {
              "fixed": "1.6.0-beta.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-22T14:31:34Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## 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\u0027s 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\u0027s 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\u0027s `_sc_config` schema, or removed entirely, the tenant admin can still create sub-tenants on the root domain \u2014 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.",
  "id": "GHSA-9237-rg5p-rhfw",
  "modified": "2026-04-22T14:31:34Z",
  "published": "2026-04-22T14:31:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/saltcorn/saltcorn/security/advisories/GHSA-9237-rg5p-rhfw"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/saltcorn/saltcorn"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "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",
      "type": "CVSS_V4"
    }
  ],
  "summary": "@saltcorn/data: Tenant user role is used for tenant creation role check"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…