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 mappingsonImportLoadForm()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 wintercms/winter@84c81f1 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 (@manus-use) for reporting the issue.
For more information
If you have any questions or comments about this advisory:
References
manus-use Reporter
Impact
Affected versions of Winter CMS did not enforce the
ImportExportControllerbehavior's granular access control on the handlers that actually perform the work.The behavior supports per-operation access control through the
import[permissions]andexport[permissions]configuration keys, enforced byuserHasAccess(). That check was applied only to theimport()andexport()page actions.Backend\Classes\Controller::execAjaxHandlers()dispatches AJAX handlers and returns beforeexecPageAction()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 mappingsonImportLoadForm()onImportLoadColumnSampleForm()onExport()— reaches$model->export()onExportLoadForm()download()— streams a completed export fileAn 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:onExport()followed bydownload(); andonImport().userHasAccess()is default-permissive — it returnstrueunless the correspondingpermissionskey 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]orexport[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 thedownload()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 underlyingimport()andexport()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 wintercms/winter@84c81f1 manually, adding the following to each of the methods listed above (using
'export'foronExport(),onExportLoadForm()anddownload()):As an interim mitigation, express the restriction in the affected controller's own
$requiredPermissionsproperty instead of relying solely on the behavior's granular keys. That check is enforced inBackend\Classes\Controllerbefore any AJAX handler is dispatched, so it covers the handlers as well as the page actions.References
Credit to Jace (@manus-use) for reporting the issue.
For more information
If you have any questions or comments about this advisory:
References