CVE-2026-125337

Winter CMS is a content management system built on the Laravel PHP framework. Prior to 1.2.14, the ImportExportController behavior applies userHasAccess() only to the import() and export() page actions, while Backend\Classes\Controller::execAjaxHandlers() dispatches onImport(), onImportLoadForm(), onImportLoadColumnSampleForm(), onExport(), and onExportLoadForm() before those gated actions run, and the separately reachable download() action also lacks the granular export check. An authenticated backend user with a valid session and coarse access through $requiredPermissions, but without the configured import[permissions] or export[permissions], can use the import handlers to write or overwrite records and can use onExport() followed by download() to retrieve the complete dataset exposed by the export model. Controllers without granular permission keys are unaffected because userHasAccess() is intentionally default-permissive. This issue is fixed in version 1.2.14.

Winter CMS is a content management system built on the Laravel PHP framework. Prior to 1.2.14, the ImportExportController behavior applies userHasAccess() only to the import() and export() page actions, while Backend\Classes\Controller::execAjaxHandlers() dispatches onImport(), onImportLoadForm(), onImportLoadColumnSampleForm(), onExport(), and onExportLoadForm() before those gated actions run, and the separately reachable download() action also lacks the granular export check. An authenticated backend user with a valid session and coarse access through $requiredPermissions, but without the configured import[permissions] or export[permissions], can use the import handlers to write or overwrite records and can use onExport() followed by download() to retrieve the complete dataset exposed by the export model. Controllers without granular permission keys are unaffected because userHasAccess() is intentionally default-permissive. This issue is fixed in version 1.2.14.

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.

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()):

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…

Winter CMS is a content management system built on the Laravel PHP framework. Prior to 1.2.14, the ImportExportController behavior applies userHasAccess() only to the import() and export() page actions, while Backend\Classes\Controller::execAjaxHandlers() dispatches onImport(), onImportLoadForm(), onImportLoadColumnSampleForm(), onExport(), and onExportLoadForm() before those gated actions run, and the separately reachable download() action also lacks the granular export check. An authenticated backend user with a valid session and coarse access through $requiredPermissions, but without the configured import[permissions] or export[permissions], can use the import handlers to write or overwrite records and can use onExport() followed by download() to retrieve the complete dataset exposed by the export model. Controllers without granular permission keys are unaffected because userHasAccess() is intentionally default-permissive. This issue is fixed in version 1.2.14.

Winter CMS is a content management system built on the Laravel PHP framework. Prior to 1.2.14, the ImportExportController behavior applies userHasAccess() only to the import() and export() page actions, while Backend\Classes\Controller::execAjaxHandlers() dispatches onImport(), onImportLoadForm(), onImportLoadColumnSampleForm(), onExport(), and onExportLoadForm() before those gated actions run, and the separately reachable download() action also lacks the granular export check. An authenticated backend user with a valid session and coarse access through $requiredPermissions, but without the configured import[permissions] or export[permissions], can use the import handlers to write or overwrite records and can use onExport() followed by download() to retrieve the complete dataset exposed by the export model. Controllers without granular permission keys are unaffected because userHasAccess() is intentionally default-permissive. This issue is fixed in version 1.2.14.

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.

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()):

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…