GHSA-FM29-4MQ3-PHG6

Winter: ImportExportController AJAX handlers bypass granular import/export permission gate

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

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.

The application does not perform an authorization check before performing a sensitive operation. Typical impact: unauthorized access to restricted functionality or data.

GHSA-FM29-4MQ3-PHG6 has a CVSS score of 8.3 (High). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (1.2.14); upgrading removes the vulnerable code path.

Kodem intelligence

Already deployed Kodem?

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.

1. What is GHSA-FM29-4MQ3-PHG6? GHSA-FM29-4MQ3-PHG6 is a high-severity missing authorization vulnerability in winter/wn-backend-module (composer), affecting versions <= 1.2.13. It is fixed in 1.2.14. The application does not perform an authorization check before performing a sensitive operation.
2. How severe is GHSA-FM29-4MQ3-PHG6? GHSA-FM29-4MQ3-PHG6 has a CVSS score of 8.3 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of winter/wn-backend-module are affected by GHSA-FM29-4MQ3-PHG6? winter/wn-backend-module (composer) versions <= 1.2.13 is affected.
4. Is there a fix for GHSA-FM29-4MQ3-PHG6? Yes. GHSA-FM29-4MQ3-PHG6 is fixed in 1.2.14. Upgrade to this version or later.
5. Is GHSA-FM29-4MQ3-PHG6 exploitable, and should I be worried? Whether GHSA-FM29-4MQ3-PHG6 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether GHSA-FM29-4MQ3-PHG6 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix GHSA-FM29-4MQ3-PHG6? Upgrade winter/wn-backend-module to 1.2.14 or later.

Other vulnerabilities in winter/wn-backend-module