Backup restore could run operating-system commands

Let me try to obtain a MySQL client to empirically test batch-mode system handling, and meanwhile inspect the web route chain.

MariaDB is installed. Now let me start it and empirically test whether the MySQL client executes OS commands from a piped SQL dump.

The MariaDB client executed system id from the piped dump. Let me confirm this rigorously and check which client variants do this.

MariaDB confirmed: system, \!, and source all execute from a piped SQL dump. Now let me check whether the actual MySQL client behaves the same.

Critical distinction confirmed: MariaDB client executes system from a piped dump; MySQL client 8.4 does not. Let me verify the deployment defaults that determine which binary is used, and the authorization on these routes.

The backups routes are nested inside the admin group (which adds authorize:superuser), so a superuser is required. Let me confirm the filename validation and do a final clean end-to-end verification with the MariaDB client.

Everything is confirmed. Let me clean up the test environment.

I have a complete, empirically verified picture. Here is the finding.

OS command injection via backup restore (mysql/mariadb client)

The one place in this codebase where a user-controlled stream is handed to an external program is the database restore flow. The external program is the mysql binary at $mysql_binary, and whether it runs local commands from the input depends on whether that binary is a MariaDB client or a MySQL client.

End-to-end chain

1. Upload — POST /backups/upload → SettingsController::postUploadBackup() (app/Http/Controllers/SettingsController.php, ~line 965) stores the attacker's zip under storage/app/backups/.
2. Restore — POST /backups/restore/{filename} → SettingsController::postRestore() (~line 999) calls Artisan::call('snipeit:restore', ['filename' => storage_path('app/backups/'.$filename), ...]).
3. Piping — app/Console/Commands/RestoreFromBackup.php extracts the single SQL stream from the zip ($sql_contents = $za->getStream(...), line ~425) and opens the external program with fixed, escapeshellarg'd arguments (line ~459):

   $proc_results = proc_open("$mysql_binary -h <host> -u <user> -P <port> <db>",
       [0 => ['pipe','r'], 1 => ['pipe','w'], 2 => ['pipe','w']], $pipes, null, $env_vars);

   In the default web path (--sanitize-with-prefix is null), the raw dump is written verbatim into the client's stdin (lines ~496–507). The arguments are fixed and safe — the payload is entirely in the piped content, exactly the case the task targets.

Required user and preconditions

• User: a superuser (the backups routes are nested inside the admin group in routes/web.php line 156, which adds the authorize:superuser permission check; the inner group only adds auth).
• app.lock_passwords must be false (not demo/locked mode).
• DB_DUMP_PATH (default /usr/local/bin, .env.example uses /usr/bin) must contain a mysql binary.

Does the program execute commands from its input?

I installed and tested both client families against a live server:

So the binary matters. In the reference Docker deployment (Dockerfile installs Debian mysql-client, which is the MariaDB client; docker-compose.yml uses mariadb:11.4.7), DB_DUMP_PATH=mysql points at a MariaDB client, so the flow is exploitable. MariaDB's client interprets system <cmd>, \! <cmd>, and source <file> from stdin even in batch mode; MySQL's client does not.

Impact

Arbitrary OS command execution as the web server (PHP-FPM/Apache) process user, reachable through the ordinary backup-restore feature. A superuser uploading a crafted zip whose SQL dump contains system <cmd> (or \! <cmd>) then hits the restore endpoint and the command runs as the PHP user. (The flow also runs db:wipe + migrate, so the same user can destroy/replace the database — but the OS command execution is the escalation beyond the app's admin model.)

Other external-program sites examined (no finding)

• app/Console/Commands/Version.php — shell_exec('git ...'), passthru('npm run prod'): CLI-only, arguments are fixed prompts, no user-controlled file/stream.
• upgrade.php — git/composer/artisan shell calls in a CLI upgrade script; not web-reachable.
• app/Console/Commands/LdapTroubleshooter.php — builds ldapsearch with escapeshellarg'd values; CLI diagnostic.
• app/Http/Controllers/StorageProxyController.php — fpassthru($stream) streams an S3 object to the response; pure PHP, no external program.
• spatie/laravel-backup backup:run (vendor, not installed here) — invokes mysqldump with DB connection config (not user-controlled content) and zips with PHP ZipArchive.

Suggested fix (for reference)

Reject/strip meta-commands from the dump before piping: filter out lines starting with system, \!, and source (and their uppercase variants) when writing to $pipes[0], or pipe through the existing SQLStreamer sanitizer even in the default (non-clean) path. Alternatively, use a MySQL client that does not interpret meta-commands in batch mode, or invoke mysql with --binary-mode/a dedicated import path that never parses client meta-commands.