{"answers":{"affected":"2 open source packages ship an affected version, including winter/wn-backend-module.","exploited":"There is no known exploitation of GHSA-fm29-4mq3-phg6 in the wild and no public exploit code.","fix":"Upgrade winter/wn-backend-module to 1.2.14 or later.","what":"GHSA-fm29-4mq3-phg6 is a missing authorization vulnerability in winter/wn-backend-module, published on 20 Aug 2026. Any signed-in user can exploit it over the network, with no action from the victim."},"fix_prompt":"Check this codebase for GHSA-fm29-4mq3-phg6 and fix it if it is affected.\n\nWhat it is: GHSA-fm29-4mq3-phg6 is a missing authorization vulnerability in winter/wn-backend-module, published on 20 Aug 2026. Any signed-in user can exploit it over the network, with no action from the victim.\nExploitation: There is no known exploitation of GHSA-fm29-4mq3-phg6 in the wild and no public exploit code.\n\nAffected packages and fixed versions:\n- winter/wn-backend-module (Packagist): affected all versions; fixed in 1.2.14\n- winter/wn-backend-module (Packagist): affected all versions; fixed in 1.2.14\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/GHSA-fm29-4mq3-phg6/ (Markdown: https://insights.sbomify.com/GHSA-fm29-4mq3-phg6/index.md)","id":"GHSA-fm29-4mq3-phg6","markdown":"https://insights.sbomify.com/GHSA-fm29-4mq3-phg6/index.md","name":"GHSA-fm29-4mq3-phg6","record":{"aliases":[],"analysis":{"component_type":"web_application","fix_type":"patch","impacts":["data_read","data_modify"],"network_reachable":"yes","non_default_config":true,"product_category":"Winter CMS plugin","requires_auth":"low_privilege","summary":"Authenticated backend users can bypass granular import/export permission checks to exfiltrate data or modify records in Winter CMS.","user_interaction":"not_required","vuln_class":"missing_authorization"},"analysis_generated_by":"qwen3.8-flash-next","assigner":null,"cpe":[],"cvss":{"score":null,"severity":null,"source":null,"vector":null,"version":null},"cwes":[],"description":"### Impact\n\nAffected versions of Winter CMS did not enforce the `ImportExportController` behavior's 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()` — reaches `$model-\u003eimport()` with attacker-supplied column mappings\n- `onImportLoadForm()`\n- `onImportLoadColumnSampleForm()`\n- `onExport()` — reaches `$model-\u003eexport()`\n- `onExportLoadForm()`\n- `download()` — 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 — 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.\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's 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 — 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 `'export'` for `onExport()`, `onExportLoadForm()` and `download()`):\n\n```php\nif (!$this-\u003euserHasAccess('import')) {\n    abort(403);\n}\n```\n\nAs 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.\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)","ecosystems":["Packagist"],"exploits":{"exploitdb":null,"first_seen":null,"github_poc":null,"max_poc_stars":null,"metasploit":null,"nuclei":null,"refs":[],"tier":null},"has_fix":true,"headline":"Winter: ImportExportController AJAX handlers bypass granular import/export permission gate","id":"GHSA-fm29-4mq3-phg6","indexable":true,"kev":null,"kind":"advisory","links":{"ecosystem":"Packagist","product":null,"products":[],"type":"missing_authorization","year":"2026"},"n_packages":2,"n_references":null,"packages":[{"ecosystem":"Packagist","fixed":["1.2.14"],"introduced":["0"],"last_affected":[],"package":"winter/wn-backend-module","purl":null,"source":"GHSA-fm29-4mq3-phg6"},{"ecosystem":"Packagist","fixed":["1.2.14"],"introduced":["0"],"last_affected":[],"package":"winter/wn-backend-module","purl":"pkg:composer/winter/wn-backend-module","source":"GHSA-fm29-4mq3-phg6"}],"products":null,"published":"2026-08-20","related":[],"sources":[{"class":"attribution","licence":"CC BY 4.0","name":"GitHub Advisory Database","prefix":"GHSA"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":null,"updated":null,"vendors":null},"summary":"Authenticated backend users can bypass granular import/export permission checks to exfiltrate data or modify records in Winter CMS.","url":"https://insights.sbomify.com/GHSA-fm29-4mq3-phg6/"}