security: RestoreEngine staging path uses unsanitized $record->tag #77

New Issue

2026-06-21T23:01:30Z

jmiller commented

2026-06-21 23:01:30 +00:00

Severity: HIGH

RestoreEngine at line 80 constructs the staging directory path using $record->tag directly from the database without sanitization:

$this->stagingDir = JPATH_ROOT . '/tmp/mokosuitebackup-restore-' . $record->tag;

A crafted tag like ../../etc/ would resolve outside /tmp/, allowing file extraction to arbitrary locations.

Similarly, SnapshotRestoreEngine at line 79 trusts $record->data_file from DB without validating it stays within the backup directory.

Fix

Sanitize tag: preg_replace('/[^a-zA-Z0-9_-]/', '', $record->tag)
Validate data_file: check realpath() stays within BackupDirectory::getDefaultAbsolute()

Files

src/Engine/RestoreEngine.php:80
src/Engine/SnapshotRestoreEngine.php:79

## Severity: HIGH `RestoreEngine` at line 80 constructs the staging directory path using `$record->tag` directly from the database without sanitization: ```php $this->stagingDir = JPATH_ROOT . '/tmp/mokosuitebackup-restore-' . $record->tag; ``` A crafted tag like `../../etc/` would resolve outside `/tmp/`, allowing file extraction to arbitrary locations. Similarly, `SnapshotRestoreEngine` at line 79 trusts `$record->data_file` from DB without validating it stays within the backup directory. ## Fix Sanitize tag: `preg_replace('/[^a-zA-Z0-9_-]/', '', $record->tag)` Validate data_file: check `realpath()` stays within `BackupDirectory::getDefaultAbsolute()` ## Files - `src/Engine/RestoreEngine.php:80` - `src/Engine/SnapshotRestoreEngine.php:79`

jmiller added the component: engine label 2026-06-21 23:01:30 +00:00

jmiller referenced this issue

2026-06-21 23:04:13 +00:00

test: Deep dive audit — verify and fix all findings #81

jmiller referenced this issue from a commit

2026-06-21 23:09:43 +00:00

fix: critical and high audit findings (#81)

jmiller referenced a pull request that will close this issue

2026-06-21 23:09:56 +00:00

fix: Critical and high audit findings (#81) #83

jmiller closed this issue

2026-06-21 23:10:23 +00:00