Package Instance

Saltcorn Server allows logged-in users to delete arbitrary files because of a path traversal vulnerability
A logged-in user with any role can delete arbitrary files on the filesystem by calling the `sync/clean_sync_dir` endpoint. The `dir_name` POST parameter is not validated/sanitized and is used to construct the `syncDir` that is deleted by calling `fs.rm`.

@saltcorn/server Remote Code Execution (RCE) / SQL injection via prototype pollution  by manipulating `lang` and  `defstring` parameters when setting localizer strings
The endpoint `/site-structure/localizer/save-string/:lang/:defstring` accepts two parameter values: `lang` and `defstring`. These values are used in an unsafe way to set the keys and value of the `cfgStrings` object. It allows to add/modify properties of the `Object prototype` that result in several logic issues, including:
- RCE vulnerabilities by polluting the `tempRootFolder` property
- SQL injection vulnerabilities by polluting the `schema` property when using `PostgreSQL` database.

Saltcorn Server Stored Cross-Site Scripting (XSS) in event logs page
Event log data is not properly sanitized leading to stored Cross-Site Scripting (XSS) vulnerability.

@saltcorn/server arbitrary file and directory listing when accessing build mobile app results
A user with admin permission can read arbitrary file and directory names on the filesystem by calling the `admin/build-mobile-app/result?build_dir_name=` endpoint.  The `build_dir_name` parameter is not properly validated and it's then used to construct the `buildDir` that is read. The file/directory names under the `buildDir` will be returned.

Saltcorn has an Unauthenticated Path Traversal in sync endpoints, allowing arbitrary file write and directory read
### Summary

Two unauthenticated path traversal vulnerabilities exist in Saltcorn's mobile sync endpoints. The `POST /sync/offline_changes` endpoint allows an unauthenticated attacker to create arbitrary directories and write a `changes.json` file with attacker-controlled JSON content anywhere on the server filesystem. The `GET /sync/upload_finished` endpoint allows an unauthenticated attacker to list arbitrary directory contents and read specific JSON files.

The safe path validation function `File.normalise_in_base()` exists in the codebase and is correctly used by the `clean_sync_dir` endpoint in the **same file** (fix for GHSA-43f3-h63w-p6f6), but was not applied to these two endpoints.

### Details

**Finding 1: Arbitrary file write — `POST /sync/offline_changes` (sync.js line 226)**

The `newSyncTimestamp` parameter from the request body is used directly in `path.join()` without sanitization:

```javascript
const syncDirName = `${newSyncTimestamp}_${req.user?.email || "public"}`;
const syncDir = path.join(
    rootFolder.location, "mobile_app", "sync", syncDirName
);
await fs.mkdir(syncDir, { recursive: true });        // creates arbitrary dir
await fs.writeFile(
    path.join(syncDir, "changes.json"),
    JSON.stringify(changes)                           // writes attacker content
);
```

No authentication middleware is applied to this route. Since `path.join()` normalizes `../` sequences, setting `newSyncTimestamp` to `../../../../tmp/evil` causes the path to resolve outside the sync directory.

**Finding 2: Arbitrary directory read — `GET /sync/upload_finished` (sync.js line 288)**

The `dir_name` query parameter is used directly in `path.join()` without sanitization:

```javascript
const syncDir = path.join(
    rootFolder.location, "mobile_app", "sync", dir_name
);
let entries = await fs.readdir(syncDir);
```

Also unauthenticated. An attacker can list directory contents and read files named `translated-ids.json`, `unique-conflicts.json`, `data-conflicts.json`, or `error.json` from any directory.

**Contrast — fixed endpoint in the same file (line 342):**

The `clean_sync_dir` endpoint correctly uses `File.normalise_in_base()`:

```javascript
const syncDir = File.normalise_in_base(
    path.join(rootFolder.location, "mobile_app", "sync"),
    dir_name
);
if (syncDir) await fs.rm(syncDir, { recursive: true, force: true });
```

### PoC

```bash
# Write arbitrary file to /tmp/
curl -X POST http://TARGET:3000/sync/offline_changes \
  -H "Content-Type: application/json" \
  -d '{
    "newSyncTimestamp": "../../../../tmp/saltcorn_poc",
    "oldSyncTimestamp": "0",
    "changes": {"proof": "path_traversal_write"}
  }'
# Result: /tmp/saltcorn_poc_public/changes.json created with attacker content

# List /etc/ directory
curl "http://TARGET:3000/sync/upload_finished?dir_name=../../../../etc"
```

### Impact

- **Unauthenticated arbitrary directory creation** anywhere on the filesystem
- **Unauthenticated arbitrary JSON file write** (`changes.json`) to any writable directory
- **Unauthenticated directory listing** of arbitrary directories
- **Unauthenticated read** of specific JSON files from arbitrary directories
- Potential for **remote code execution** via writing to sensitive paths (cron, systemd, Node.js module paths)

### Remediation

Apply `File.normalise_in_base()` to both endpoints, matching the existing pattern in `clean_sync_dir`:

```javascript
// offline_changes fix
const syncDirName = `${newSyncTimestamp}_${req.user?.email || "public"}`;
const syncDir = File.normalise_in_base(
    path.join(rootFolder.location, "mobile_app", "sync"),
    syncDirName
);
if (!syncDir) {
    return res.status(400).json({ error: "Invalid sync directory name" });
}

// upload_finished fix
const syncDir = File.normalise_in_base(
    path.join(rootFolder.location, "mobile_app", "sync"),
    dir_name
);
if (!syncDir) {
    return res.json({ finished: false });
}
```

Additionally, add `loggedIn` middleware to endpoints that modify server state.

Saltcorn: SQL Injection via Unparameterized Sync Endpoints (maxLoadedId)
### Summary
A critical SQL injection vulnerability in Saltcorn’s mobile-sync routes allows any authenticated low-privilege user with read access to at least one table to inject arbitrary SQL through sync parameters. This can lead to full database exfiltration, including admin password hashes and configuration secrets, and may also enable database modification or destruction depending on the backend. 

### Details
The issue affects the mobile-sync endpoints:

- `POST /sync/load_changes`
- `POST /sync/deletes`

According to the provided analysis, user-controlled values from the request body are interpolated directly into SQL template literals without parameterization, type enforcement, or sanitization. In particular, `req.body.syncInfos[tableName].maxLoadedId` is embedded into SQL in `getSyncRows()` and timestamp-derived values are similarly interpolated in `getDelRows()`. 

Relevant vulnerable code paths include:

- `packages/server/routes/sync.js` — `getSyncRows()`
  - branch using `where data_tbl."${db.sqlsanitize(pkName)}" > ${syncInfo.maxLoadedId}`
  - branch using `and info_tbl.ref > ${syncInfo.maxLoadedId}`
- `packages/server/routes/sync.js` — `getDelRows()`
  - timestamp expressions built from request-controlled values and inserted into SQL
- `packages/server/routes/sync.js` — `/load_changes` route handler
  - request body fields are passed into the SQL-building functions without validation or safe binding

The root cause is that values are treated as trusted SQL fragments rather than bound parameters. While `db.sqlsanitize()` is used for identifiers elsewhere, that does not protect interpolated values and is not intended to prevent value-based SQL injection. The report notes there is no `parseInt()`, numeric validation, or prepared-statement binding before these values are concatenated into the query string. 

This means a normal authenticated user can escape the intended query logic and execute arbitrary SQL in the context of the application database. The provided evidence demonstrates successful extraction of user records and schema information through the vulnerable sync route, confirming that the injection is practically exploitable. 

### PoC
Based on the provided report, the issue can be reproduced by authenticating as a normal user, sending a crafted request to the affected sync endpoint, and placing a malicious SQL expression into the sync metadata field that is later interpolated into the backend query. Successful exploitation returns attacker-selected database contents in the sync response. 

### Impact
- **Type:** SQL injection
- **Who is impacted:** Any Saltcorn deployment exposing the affected mobile-sync routes to authenticated users
- **Security impact:** An authenticated low-privilege user may exfiltrate the full database, including password hashes, configuration secrets, application data, and schema information; on some backends, the same flaw may also permit writes, schema changes, or destructive operations
- **Attack preconditions:** The attacker needs a valid authenticated account with access to at least one readable table through the sync feature
- **Privilege impact:** The issue allows escalation from normal user access to database-wide compromise

Saltcorn: Open Redirect in `POST /auth/login` due to incomplete `is_relative_url` validation (backslash bypass)
### Summary
Saltcorn validates the post-login `dest` parameter with a string check that only blocks `:/` and `//`. Because all WHATWG-compliant browsers normalise backslashes (`\`) to forward slashes (`/`) for special schemes, a payload such as `/\evil.com/path` slips through `is_relative_url()`, is emitted unchanged in the HTTP `Location` header, and causes the browser to navigate cross-origin to an attacker-controlled domain. The bug is reachable on a default install and only requires a victim who can be tricked into logging in via a crafted Saltcorn URL.

### Details
Vulnerable function: `packages/server/routes/utils.js:393-395`

```js
const is_relative_url = (url) => {
  return typeof url === "string" && !url.includes(":/") && !url.includes("//");
};
```

The function's intent is to allow only same-origin redirects, but the allow-list only checks for two literal substrings. It does not handle:
- backslash characters, which WHATWG URL parsing (used by every modern browser) treats as forward slashes for the special schemes `http`, `https`, `ftp`, `ws`, `wss`. A URL parser fed `/\evil.com/path` with a base of `http://victim/` resolves to `http://evil.com/path`.
- non-`http(s):` schemes that do not contain `:/`. The strings `javascript:alert(1)`, `data:text/html,...`, `vbscript:...` all pass.

Vulnerable callsite: `packages/server/auth/routes.js:1371-1376`

```js
} else if (
  (req.body || {}).dest &&
  is_relative_url(decodeURIComponent((req.body || {}).dest))
) {
  res.redirect(decodeURIComponent((req.body || {}).dest));
} else res.redirect("/");
```

The body's `dest` is URL-decoded twice (once by body-parser, once by the explicit `decodeURIComponent`) and the same value is passed to `res.redirect`. Express 5's `res.redirect` runs the value through `encodeurl@2.0.0`, whose whitelist character class `[^\x21\x23-\x3B\x3D\x3F-\x5F\x61-\x7A\x7C\x7E]` includes `\x5C` (backslash). The backslash is therefore not percent-encoded and ends up verbatim in the `Location` response header.

### PoC
[poc.zip](https://github.com/user-attachments/files/26678853/poc.zip)

Please extract the uploaded compressed file before proceeding
1. ./setup.sh
2. ./poc.sh

<img width="419" height="71" alt="스크린샷 2026-04-13 오후 11 44 36" src="https://github.com/user-attachments/assets/9c919ed4-167b-47e3-9873-733f97b44bf0" />

### Impact
Any user who can be lured into clicking a Saltcorn login URL crafted by the attacker will, after submitting their valid credentials, be redirected to an attacker-controlled origin. The redirect happens under the trusted Saltcorn domain, so the user has no visual cue that they are about to leave the site. Realistic abuse patterns:

- Credential phishing — the attacker's site renders a forged "session expired, please log in again" prompt to capture the password the user just typed.

@saltcorn/server arbitrary file zip read and download when downloading auto backups
A user with admin permission can read and download arbitrary zip files when downloading auto backups. The file name used to identify the zip file is not properly sanitized when passed to `res.download` API.