@saltcorn/data vulnerable to SQL Injection via jsexprToSQL Literal HandlerGHSA-59xv-588h-2vmm
NONEGHSA-59xv-588h-2vmm is a none-severity (CVSS 0) vulnerability in @saltcorn/data. A fix is available for @saltcorn/data — see the affected versions and patch details below.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
@saltcorn/datanpmDescription
Summary
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
Literal({ value }: { value: ExtendedNode }) {
if (typeof value == "string") return `'${value}'`; // NO ESCAPING!
return `${value}`;
},
Call chain: Formula constraint creation → table_constraints.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:
name === "test' OR '1'='1"
The jsexprToSQL() function generates:
(name)=('test' OR '1'='1')
This is then executed as:
ALTER TABLE "tablename" ADD CONSTRAINT "tablename_fml_1" CHECK ((name)=('test' OR '1'='1'));
The single quote in the string literal is not escaped, breaking out of the SQL string context.
More Dangerous Payload
name === "'; DROP TABLE users; --"
Generates:
(name)=(''; DROP TABLE users; --')
Verified on Saltcorn v1.5.0 (Docker)
Direct invocation of jsexprToSQL() inside the running container confirms the vulnerability:
Input: name === "hello"
Output: (name)=('hello') ← Normal
Input: name === "test' OR '1'='1"
Output: (name)=('test' OR '1'='1') ← Single quote NOT escaped, OR injected
Input: name === "'; DROP TABLE users; --"
Output: (name)=(''; DROP TABLE users; --') ← DROP TABLE injected
The test was performed on a completely fresh Saltcorn installation (zero user-created tables, default Docker setup).
PoC Screenshot
- Create a table after moving to the table menu
- Go to the table and then to
Constraits
- Go to
Formula
- Create a test table for verification
- Input the payload and save
- Check the table for testing
Impact
- Arbitrary SQL execution via crafted CHECK constraints
- Data exfiltration through error-based or time-based SQL injection
- Database schema manipulation (DROP TABLE, ALTER TABLE)
- Potential privilege escalation via direct
userstable modification
Suggested Remediation
Escape single quotes in the Literal handler:
Literal({ value }: { value: ExtendedNode }) {
if (typeof value == "string") return `'${value.replace(/'/g, "''")}'`;
return `${value}`;
},
Alternatively, use parameterized queries for constraint creation instead of string interpolation.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @saltcorn/data | all versions | 1.4.5npm install @saltcorn/data@1.4.5 |
| 📦npm | @saltcorn/data | ≥ 1.5.0&&< 1.5.5 | 1.5.5npm install @saltcorn/data@1.5.5 |
| 📦npm | @saltcorn/data | ≥ 1.6.0-alpha.0&&< 1.6.0-beta.4 | 1.6.0-beta.4npm install @saltcorn/data@1.6.0-beta.4 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @saltcorn/data, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update @saltcorn/data to 1.4.5 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-59xv-588h-2vmm is resolved across your whole dependency graph.
Workarounds
Until you can upgrade, make sure every query built from user input uses parameterised statements or a prepared-statement API rather than string concatenation, and reduce the database account's privileges so an injected query cannot read or alter data beyond what the feature needs.
Frequently Asked Questions
Is GHSA-59xv-588h-2vmm in your dependencies?
Find it across npm, including transitive dependencies.