{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.2.13"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "winter/wn-backend-module"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.2.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-862",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-20T18:44:50Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\n\nAffected versions of Winter CMS did not enforce the `ImportExportController` behavior\u0027s granular access control on the handlers that actually perform the work.\n\nThe 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.\n\n`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:\n\n- `onImport()` \u2014 reaches `$model-\u003eimport()` with attacker-supplied column mappings\n- `onImportLoadForm()`\n- `onImportLoadColumnSampleForm()`\n- `onExport()` \u2014 reaches `$model-\u003eexport()`\n- `onExportLoadForm()`\n- `download()` \u2014 streams a completed export file\n\nAn 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:\n\n- **exfiltrate** the entire dataset exposed by the export model, via `onExport()` followed by `download()`; and\n- **write or overwrite** records through the import model, via `onImport()`.\n\n`userHasAccess()` is default-permissive \u2014 it returns `true` unless the corresponding `permissions` key is configured \u2014 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.\n\nNote that CSRF tokens are still verified on all POST requests, so the attacker must be logged into the backend with a valid session.\n\nTo 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\u0027s own `$requiredPermissions`.\n\n### Patches\n\n`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.\n\nBecause 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 \u2014 which is the intended fix.\n\nRegression 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.\n\nThis security issue has been fixed in [v1.2.14](https://github.com/wintercms/winter/commit/84c81f153f2dc3e2c7b03ab14a4a3ca8456d0e4f).\n\n### Workarounds\n\nIf you cannot upgrade, apply https://github.com/wintercms/winter/commit/84c81f153f2dc3e2c7b03ab14a4a3ca8456d0e4f manually, adding the following to each of the methods listed above (using `\u0027export\u0027` for `onExport()`, `onExportLoadForm()` and `download()`):\n\n```php\nif (!$this-\u003euserHasAccess(\u0027import\u0027)) {\n    abort(403);\n}\n```\n\nAs an interim mitigation, express the restriction in the affected controller\u0027s own `$requiredPermissions` property instead of relying solely on the behavior\u0027s 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.\n\n### References\n\nCredit to Jace ([@manus-use](https://github.com/manus-use)) for reporting the issue.\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n- Email us at [hello@wintercms.com](mailto:hello@wintercms.com)",
  "id": "GHSA-fm29-4mq3-phg6",
  "modified": "2026-08-21T19:10:20Z",
  "published": "2026-08-20T18:44:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/wintercms/winter/security/advisories/GHSA-fm29-4mq3-phg6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/wintercms/winter/commit/84c81f153f2dc3e2c7b03ab14a4a3ca8456d0e4f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/wintercms/winter"
    },
    {
      "type": "WEB",
      "url": "https://github.com/wintercms/winter/releases/tag/v1.2.14"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Winter: ImportExportController AJAX handlers bypass granular import/export permission gate"
}