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