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