Snipe-IT versions prior to 8.7.0 streamed the SQL entry from an uploaded backup archive directly into the MySQL / MariaDB command-line client without the --binary-mode flag. The client interprets lines beginning with \! as local shell commands to execute on the host. A superadministrator restoring a crafted backup could achieve remote code execution as the web application's operating-system user.

Impact

A superadministrator can execute arbitrary shell commands as the Snipe-IT web-service account. On the official Docker image, this ran as uid=10000(docker) in the reporter's proof. Typical consequences:

• Read of application secrets, including database credentials and APP_KEY
• Read and write of Snipe-IT data and persistent storage
• Modification of application-writable files
• Potential container escape depending on the deployment's mounts and privileges

The chain requires an authenticated superadministrator session. Where a separate authentication or privilege-escalation vulnerability grants superadministrator access, the combined chain warrants a higher score than this standalone finding.

Vector

1. Attacker signs in as a superadministrator.
2. Attacker crafts a ZIP backup whose .sql entry begins with a MariaDB client command such as \! /usr/bin/id > /tmp/marker.
3. Attacker uploads the archive via POST /admin/backups/upload.
4. Attacker triggers the restore via POST /admin/backups/restore/{filename} without the clean form parameter. DB_SANITIZE_BY_DEFAULT is false by default, so the sanitizer is not applied on the default restore path.
5. snipeit:restore opens proc_open on the mysql binary and pipes the SQL bytes into stdin. Without --binary-mode, the client interprets \! COMMAND as "run COMMAND on the host as this process's OS user". The command executes with the web application's privileges.

Preconditions:

• Attacker is authenticated as a Snipe-IT superadministrator
• Backup upload and restore are enabled (default when APP_LOCKED=false)
• The deployment uses the supported MySQL / MariaDB restore path with the mysql client installed (the official Docker image satisfies this)
• The clean sanitizer parameter is not applied (default)

Affected versions

< 8.7.0

Patched versions

8.7.0

Fix

Commit f511ce490951bf8e09cd4bd62ab8d72f3e4457e0 ("Refactor import code, improve error messaging, speed up MySQL import") added the --binary-mode flag to the mysql client invocation in app/Console/Commands/RestoreFromBackup.php. Per the MySQL / MariaDB documentation, --binary-mode disables the client's local-command interpretation of \!, \., system, source, and equivalent backslash commands in non-interactive input, closing the specific execution primitive this finding exploits.

The reporter also suggested layered hardening beyond the specific --binary-mode fix:

• Server-side always-sanitize as the default posture rather than the current opt-in checkbox controlled by DB_SANITIZE_BY_DEFAULT
• Explicit rejection of \!, system, source, and other client-command lines before the SQL stream reaches the CLI, accounting for whitespace and buffer boundaries
• Argv-array proc_open invocation rather than a shell command string
• Minimal filesystem and container permissions on the app service account

The --binary-mode flag closes the specific execution path used in this finding. The layered hardening above is tracked separately as follow-up work.

Severity

CVSS v3.1: 7.2 High (AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H)

Weakness

CWE-78: Improper Neutralization of Special Elements Used in an OS Command (OS Command Injection)

Credit

Submersion.ai Security Research Team