CVE-2026-49976

Snipe-IT is an IT asset/license management system. Prior to 8.6.1, a user with the import permission can use CSV update mode to overwrite the email address of a non-admin user and then request a password reset to take over that account. app/Importer/UserImporter.php applies the canEditAuthFields gate by unsetting username, email, password, and activated on the model, but app/Importer/ItemImporter.php sanitizeItemForUpdating() rebuilds the update array from the raw CSV row in $this->item, restoring the unauthorized values. The app/Http/Controllers/ImportController.php import path checks import permission but does not require users.edit. This issue is fixed in version 8.6.1.

Snipe-IT is an IT asset/license management system. Prior to 8.6.1, a user with the import permission can use CSV update mode to overwrite the email address of a non-admin user and then request a password reset to take over that account. app/Importer/UserImporter.php applies the canEditAuthFields gate by unsetting username, email, password, and activated on the model, but app/Importer/ItemImporter.php sanitizeItemForUpdating() rebuilds the update array from the raw CSV row in $this->item, restoring the unauthorized values. The app/Http/Controllers/ImportController.php import path checks import permission but does not require users.edit. This issue is fixed in version 8.6.1.

Impact

The CSV user import in update mode bypasses user-edit authorization. A user with only the import permission can overwrite any non-admin user's email by uploading a CSV, then trigger a password reset to take over the account.

UserImporter.php checks the canEditAuthFields gate and tries to strip auth fields from the model:

// app/Importer/UserImporter.php:107-114
if (Auth::check() && (! Gate::allows('canEditAuthFields', $user))) {
    unset($user->username);
    unset($user->email);
    unset($user->password);
    unset($user->activated);
}
$user->update($this->sanitizeItemForUpdating($user));

The unset()s operate on the model, but sanitizeItemForUpdating() rebuilds its array from $this->item (the raw CSV row), not from the model:

// app/Importer/ItemImporter.php:135-149
protected function sanitizeItemForStoring($model, $updating = false)
{
    $item = collect($this->item);                  // CSV data, not model attributes
    $item = $item->only($model->getFillable());
    if ($updating) {
        $item = $item->reject(fn($v) => empty($v));
    }
    return $item->toArray();
}

The attacker's CSV values pass through untouched.

For non-admin attacker vs. non-admin, non-superuser target, the gate returns true at AuthServiceProvider.php:137, so the unset() block never executes. The entire import path checks only $this->authorize('import') (ImportController.php:196); no users.edit check anywhere. The normal API route PATCH /api/v1/users/{id} correctly returns 403 for the same user.

Attacker must have import privileges to exploit this, and that permission must be granted specifically and intentionally by a superadmin.

Patches

Patched in v8.6.0

Snipe-IT is an IT asset/license management system. Prior to 8.6.1, a user with the import permission can use CSV update mode to overwrite the email address of a non-admin user and then request a password reset to take over that account. app/Importer/UserImporter.php applies the canEditAuthFields gate by unsetting username, email, password, and activated on the model, but app/Importer/ItemImporter.php sanitizeItemForUpdating() rebuilds the update array from the raw CSV row in $this->item, restoring the unauthorized values. The app/Http/Controllers/ImportController.php import path checks import permission but does not require users.edit. This issue is fixed in version 8.6.1.

Snipe-IT is an IT asset/license management system. Prior to 8.6.1, a user with the import permission can use CSV update mode to overwrite the email address of a non-admin user and then request a password reset to take over that account. app/Importer/UserImporter.php applies the canEditAuthFields gate by unsetting username, email, password, and activated on the model, but app/Importer/ItemImporter.php sanitizeItemForUpdating() rebuilds the update array from the raw CSV row in $this->item, restoring the unauthorized values. The app/Http/Controllers/ImportController.php import path checks import permission but does not require users.edit. This issue is fixed in version 8.6.1.

Impact

The CSV user import in update mode bypasses user-edit authorization. A user with only the import permission can overwrite any non-admin user's email by uploading a CSV, then trigger a password reset to take over the account.

UserImporter.php checks the canEditAuthFields gate and tries to strip auth fields from the model:

// app/Importer/UserImporter.php:107-114
if (Auth::check() && (! Gate::allows('canEditAuthFields', $user))) {
    unset($user->username);
    unset($user->email);
    unset($user->password);
    unset($user->activated);
}
$user->update($this->sanitizeItemForUpdating($user));

The unset()s operate on the model, but sanitizeItemForUpdating() rebuilds its array from $this->item (the raw CSV row), not from the model:

// app/Importer/ItemImporter.php:135-149
protected function sanitizeItemForStoring($model, $updating = false)
{
    $item = collect($this->item);                  // CSV data, not model attributes
    $item = $item->only($model->getFillable());
    if ($updating) {
        $item = $item->reject(fn($v) => empty($v));
    }
    return $item->toArray();
}

The attacker's CSV values pass through untouched.

For non-admin attacker vs. non-admin, non-superuser target, the gate returns true at AuthServiceProvider.php:137, so the unset() block never executes. The entire import path checks only $this->authorize('import') (ImportController.php:196); no users.edit check anywhere. The normal API route PATCH /api/v1/users/{id} correctly returns 403 for the same user.

Attacker must have import privileges to exploit this, and that permission must be granted specifically and intentionally by a superadmin.

Patches

Patched in v8.6.0