WINTER/WN-BACKEND-MODULE · CVE-2026-125337 · Package
FIX → 1.2.14
In Winter CMS's wn-backend-module, the import and export AJAX handlers did not enforce the granular import or export permission configured on a controller. An authenticated backend user without that permission could export a full dataset or write records through the import model.
first public Aug 19, 2026 · 2 sources
Could this affect your app?
Free first check from your website. Connect your repo for the full answer.
Winter CMS sites whose backend controllers use the ImportExportController behavior and set import[permissions] or export[permissions] more restrictively than the controller's $requiredPermissions. Controllers without those granular keys are not affected, since the default check is permissive. An attacker needs a logged-in backend account with the coarse controller permission.
Not affected if auth-required, default-config, no-granular-import-export-permissions
Who cares php, self-hosted, winter-cms, wn-backend-module
composer show winter/wn-backend-module and compare the installed version with 1.2.14.import[permissions] or export[permissions] settings.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 mappingsCheck it with your coding agent
It reads this page and tells you if your code is affected.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
userHasAccess('import') or userHasAccess('export') appears in the import and export handlers.Upgrade to 1.2.14
winter/wn-backend-module 1.2.14 (fixed version; affected <= 1.2.13).userHasAccess check to each affected method, or to express the restriction in the controller's $requiredPermissions.onImportLoadForm()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 by download(); andonImport().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.
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.
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.
Credit to Jace (@manus-use) for reporting the issue.
If you have any questions or comments about this advisory:
This page as .md · .json · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L
GitHub Advisory Database, CC-BY 4.0 · NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.