| Titel | David-Crty/databasement databasement <=1.7.3 Write-what-where Condition |
|---|
| Beschreibung |
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. |
|---|
| Quelle | ⚠️ https://github.com/David-Crty/databasement/security/advisories/GHSA-3rjj-69wh-r95f |
|---|
| Benutzer | mikannse (UID 100854) |
|---|
| Einreichung | 29.09.2026 15:19 (vor 18 Tagen) |
|---|
| Moderieren | 17.10.2026 11:48 (18 days later) |
|---|
| Status | Akzeptiert |
|---|
| VulDB Eintrag | 421587 [David-Crty Databasement bis 1.8.1 Scheduled Restore SaveScheduledRestoreRequest.php schema_name erweiterte Rechte] |
|---|
| Punkte | 20 |
|---|