| Title | David-Crty/databasement databasement <=1.7.3 Write-what-where Condition |
|---|
| Description |
When creating or updating a **scheduled restore** through the REST API, the `schema_name` field is accepted with only a length check (`max:255`) and no path validation — unlike the same field in the Livewire UI, which is validated against `SafeDatabasePath`. For SQLite targets the `schema_name` becomes the destination file path of the restore. A user with the `operate-restores` ability (the built-in `operator` or `admin` role) can therefore POST a `schema_name` pointing at any path the queue-worker process can write to, then trigger the restore to write the snapshot's bytes to that path.
This is a **default-config reachable** API/UI validation asymmetry. It was confirmed end-to-end against the published `davidcrty/databasement:1` image (app version `1.7.3`): an attacker-supplied `schema_name = "/data/POC_pwned_by_api.txt"` was accepted by the API with HTTP 201, a `run` call produced a queued job, and the queue worker created the attacker-chosen file (8192 bytes) at the requested path. |
|---|
| Source | ⚠️ https://github.com/David-Crty/databasement/security/advisories/GHSA-3rjj-69wh-r95f |
|---|
| User | mikannse (UID 100854) |
|---|
| Submission | 09/29/2026 15:19 (29 days ago) |
|---|
| Moderation | 10/17/2026 11:48 (18 days later) |
|---|
| Status | Accepted |
|---|
| VulDB entry | 421587 [David-Crty Databasement up to 1.8.1 Scheduled Restore SaveScheduledRestoreRequest.php schema_name authorization] |
|---|
| Points | 20 |
|---|