Skip to content

← Public intelligence

npm package

@saltcorn/data

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. High, CVSS 8.7npmAmendedPublished

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

    GHSA-9237-rg5p-rhfw

    Affected
    • npm @saltcorn/data < 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.21.6.0-beta.21.4.4· Vendor fix available
    Issue
    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…

    Recommended action: Upgrade to 1.6.0-beta.2 (pre-release), 1.5.2 or 1.4.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →
  2. UnratednpmAmendedPublished

    @saltcorn/data vulnerable to SQL Injection via jsexprToSQL Literal Handler

    GHSA-59xv-588h-2vmm

    Affected
    • npm @saltcorn/data < 1.4.5; >= 1.5.0, < 1.5.5; >= 1.6.0-alpha.0, < 1.6.0-beta.4
    Fixed in
    1.4.51.6.0-beta.41.5.5· Vendor fix available
    Issue
    The jsexprToSQL() function in Saltcorn converts JavaScript expressions to SQL for use in database constraints. The Literal handler wraps string values in single quotes without escaping embedded single quotes, allowing SQL injection when creating Formula-type table constraints. Vulnerable Component File: packages/saltcorn-data/models/expression.ts, lines 117-118 Call chain: Formula constraint creation → tableconstraints.ts:127 → jsexprToSQL() → Literal() → db.query() executes unsanitized SQL. Proof of Concept Injection via Formula Constraint When an admin creates a Formula-type table constraint with the expression: The jsexprToSQL() function generates: This is then executed as: The single quote in the string literal is not escaped, breaking out of the SQL string context. More Dangerous Payload Generates: Verified on Saltcorn v1.5.0 (Docker) Direct invocation of jsexprToSQL() inside the running container confirms the vulnerability: The test was performed on a completely fresh…

    Recommended action: Upgrade to 1.6.0-beta.4 (pre-release), 1.5.5 or 1.4.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →