GHSA-fm29-4mq3-phg6

### Impact Affected versions of Winter CMS did not enforce the `ImportExportController` behavior's granular access control on the handlers that actually perform the work. The behavior supports per-operation access control through the `import[permissions]` and `export[permissions]` configuration keys, enforced by `userHasAccess()`. That check was applied only to the `import()` and `export()` page actions. `Backend\Classes\Controller::execAjaxHandlers()` dispatches AJAX handlers and returns *before* `execPageAction()` runs, and the behavior binds its import and export form widgets in its constructor on every request to the controller. The handlers were therefore fully functional without the gated page action ever executing, and none of them carried the check: - `onImport()` — reaches `$model->import()` with attacker-supplied column mappings - `onImportLoadForm()` - `onImportLoadColumnSampleForm()` - `onExport()` — reaches `$model->export()` - `onExportLoadForm()` - `download()` — streams a completed export file An authenticated backend user who could reach such a controller through its coarse `$requiredPermissions`, but who was denied the granular import or export permission, could therefore: - **exfiltrate** the entire dataset exposed by the export model, via `onExport()` followed by `download()`; and - **write or overwrite** records through the import model, via `onImport()`. `userHasAccess()` is default-permissive — it returns `true` unless the corresponding `permissions` key is configured — so only controllers that declare granular import/export permissions were affected. Those are precisely the controllers whose authors opted in to restricting these operations, and for which the configuration silently had no effect on the paths that mattered. Note that CSRF tokens are still verified on all POST requests, so the attacker must be logged into the backend with a valid session. To actively exploit this issue, an attacker would need a backend account with acce