Winter CMS allows unauthorized data import and export

### 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 access to a controller that implements this behavior and declares an `import[permissions]` or `export[permissions]` value more restrictive than that controller's own `$requiredPermissions`.

### Patches

`userHasAccess()` is now enforced on every handler and action that performs or exposes an import or export operation: `onImport()`, `onImportLoadForm()`, `onImportLoadColumnSampleForm()`, `onExport()`, `onExportLoadForm()`, and the `download()` action.

Because the check remains default-permissive, controllers that never configured granular permissions are unaffected. The only behavioural change is for controllers that did configure the gate — which is the intended fix.

Regression coverage was added in `modules/backend/tests/behaviors/ImportExportControllerPermissionsTest.php`, covering denial of each guarded entry point, proof that the underlying `import()` and `export()` model sinks are never reached, positive controls confirming a user who does hold the granular permissions is still able to import and export, and a control confirming that controllers without the configuration continue to work.

This security issue has been fixed in [v1.2.14](https://github.com/wintercms/winter/commit/84c81f153f2dc3e2c7b03ab14a4a3ca8456d0e4f).

### Workarounds

If you cannot upgrade, apply https://github.com/wintercms/winter/commit/84c81f153f2dc3e2c7b03ab14a4a3ca8456d0e4f manually, adding the following to each of the methods listed above (using `'export'` for `onExport()`, `onExportLoadForm()` and `download()`):

```php
if (!$this->userHasAccess('import')) {
abort(403);
}
```

As an interim mitigation, express the restriction in the affected controller's own `$requiredPermissions` property instead of relying solely on the behavior's granular keys. That check is enforced in `Backend\Classes\Controller` before any AJAX handler is dispatched, so it covers the handlers as well as the page actions.

### References

Credit to Jace ([@manus-use](https://github.com/manus-use)) for reporting the issue.

### For more information

If you have any questions or comments about this advisory:
- Email us at [[email protected]](mailto:[email protected])