# GHSA-fm29-4mq3-phg6: Winter: ImportExportController AJAX handlers bypass granular import/export permission gate

> Authenticated backend users can bypass granular import/export permission checks to exfiltrate data or modify records in Winter CMS.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Any signed-in user
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 20 Aug 2026

## What is GHSA-fm29-4mq3-phg6?

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.

### Official description

### 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 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`.

### 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](https://github.com/wintercms/winter/commit/84c81f153f2dc3e2c7b03ab14a4a3ca8456d0e4f).

### Workarounds

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()`):

```php
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](https://github.com/manus-use)) for reporting the issue.

### For more information

If you have any questions or comments about this advisory:
- Email us at [hello@wintercms.com](mailto:hello@wintercms.com)

## Which versions are affected by GHSA-fm29-4mq3-phg6?

2 open source packages ship an affected version, including winter/wn-backend-module.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `winter/wn-backend-module` | Packagist | All versions | 1.2.14 |
| `winter/wn-backend-module` | Packagist | All versions | 1.2.14 |

## How do I fix GHSA-fm29-4mq3-phg6?

Upgrade winter/wn-backend-module to 1.2.14 or later.

## Is GHSA-fm29-4mq3-phg6 being exploited?

There is no known exploitation of GHSA-fm29-4mq3-phg6 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-fm29-4mq3-phg6 and fix it if it is affected.

What 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.
Exploitation: There is no known exploitation of GHSA-fm29-4mq3-phg6 in the wild and no public exploit code.

Affected packages and fixed versions:
- winter/wn-backend-module (Packagist): affected all versions; fixed in 1.2.14
- winter/wn-backend-module (Packagist): affected all versions; fixed in 1.2.14

Task:
1. 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.
2. 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.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/GHSA-fm29-4mq3-phg6/ (Markdown: https://insights.sbomify.com/GHSA-fm29-4mq3-phg6/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-fm29-4mq3-phg6

---
From sbomify Insights: https://insights.sbomify.com/GHSA-fm29-4mq3-phg6/
Summaries are generated and may contain mistakes; the official description above is the record.