winter/wn-backend-module

Impact

Affected versions of Winter CMS render the search query parameter without HTML encoding inside a <script type="text/template"> block in the backend Table widget partial (modules/backend/widgets/table/partials/_table.php):

value="<?= get('search') ?>"

<script> is an HTML raw-text context, so the surrounding value="…" attribute quoting is not a parser boundary. A literal </script> in the query string terminates the template element early, and everything after it is parsed as ordinary markup in the backend document.

Any backend page rendering a Table or DataTable widget is a sink. The value is read from the global request through the get() helper, which — unlike post() — is not restricted by HTTP method, so a plain top-level GET navigation is sufficient. The template is also emitted unconditionally by the partial, so widgets using the default searching: false configuration are equally affected.

In Winter core the reachable route is the Editor Settings form (/backend/system/settings/update/winter/backend/editor), which renders six datatable fields and is gated by backend.manage_editor — assigned by default to the built-in Developer role. Third-party plugins using the datatable form widget, or the Table widget directly, expose the same sink on their own pages.

An attacker who induces a signed-in backend user to follow a crafted link executes script in that user's authenticated backend origin. The injected script can read the CSRF token published in the backend layout's <meta name="csrf-token"> element and issue credentialed requests as the victim, bounded only by that user's permissions. Because the core sink requires backend.manage_editor, the practical victim is a Developer-role user or superuser — who can edit CMS templates, so script running in that session can chain to server-side code execution.

This is not a permission bypass: the victim must already be authorised for the page, and the attacker gains no permission the victim does not hold.

To actively exploit this issue, an attacker needs no account of their own, but does need an authenticated backend user with access to a page rendering a Table or DataTable widget to follow an attacker-supplied link.

Patches

The search value is now HTML-encoded on output, matching every other value rendered by the same partial and the equivalent handling in the backend Search widget (modules/backend/widgets/search/partials/_search.php):

value="<?= e(get('search')); ?>"

This removes the raw-text terminator: the browser can no longer encounter an attacker-supplied literal </script> while tokenising the document. The template is subsequently parsed once by jQuery when the toolbar is built, so an encoded payload resolves to an inert attribute string rather than markup.

Regression coverage was added in modules/backend/tests/widgets/TableSearchEscapingTest.php, covering plain, mixed-case (</ScRiPt>) and whitespace-bearing (</script >) terminators, both searching states, and preservation of ordinary and Unicode search text.

This security issue has been fixed in v1.2.14.

Workarounds

If you cannot upgrade, apply https://github.com/wintercms/winter/commit/1b6397654124fb44a6abf6f3782b6a1d746cef14 manually — in modules/backend/widgets/table/partials/_table.php, change:

value="<?= get('search') ?>"

to:

value="<?= e(get('search')); ?>"

A restrictive Content Security Policy served at the web server or reverse proxy can reduce practical exploitability, but it is not a substitute for the fix: Winter's backend ships inline scripts, so a policy permissive enough to run the backend may still permit an injected execution primitive.

References

Credit to Awwader (@NRAwwad) for reporting the issue.

For more information

If you have any questions or comments about this advisory:

• Email us at hello@wintercms.com

Impact

Affected versions of Winter CMS allow a backend AJAX handler to be invoked by a plain top-level GET navigation with no CSRF token. Backend\Classes\Controller::actionExists() accepted any public method on a controller as a page action, so handler-shaped names were never reserved from URL dispatch: an authenticated and authorized request to /backend/system/eventlogs/index_onEmptyLog reached the handler of the same name and truncated the system event log. Backend paths are routed through Route::any, and CSRF validation is skipped for HEAD, GET and OPTIONS requests.

The default SameSite=Lax session cookie is sent on top-level cross-site navigation, so a link on an attacker-controlled page is sufficient — no form, no script and no token. Handler arguments are taken from URL path segments, so the attacker also chooses the target record. Affected handlers across the backend, cms and system modules cover log truncation, resetting settings to their defaults, altering backend user state, and deleting CMS templates. None of them disclose data to the attacker or write attacker-controlled content, so the impact is destructive and state-changing rather than confidential.

To actively exploit this issue, an attacker would need no account of their own, but would need an authenticated backend user holding the relevant permission to follow an attacker-supplied link. The permissions guarding the affected handlers, system.access_logs included, are by default assigned only to the built-in Developer role.

Patches

Page-action dispatch is now restricted to all-lowercase method names, which reserves handler-shaped names (onFoo, index_onFoo) from being reached by URL. AJAX dispatch is unchanged: handlers continue to work over POST with the X-WINTER-REQUEST-HANDLER header exactly as before, and need no changes.

IMPORTANT: This fix includes a breaking change to backend action routing. A public controller method used as a page action must now be named in lowercase — coming_soon() rather than comingSoon() — and dashed URLs are normalised to snake_case, so /coming-soon now resolves to coming_soon() instead of comingSoon(). Plugins with a camelCase page action should rename the method and its view file to match; the published URL does not need to change. Core is unaffected, and a survey of the plugin ecosystem found the change affects only a small number of plugins.

This security issue has been fixed in v1.2.14.

Workarounds

If you cannot upgrade, apply https://github.com/wintercms/winter/commit/353b23804dee2acf49fca996c72637040446824f manually.

As an interim mitigation, set 'same_site' => 'strict' in config/session.php. A strict session cookie is not sent on cross-site top-level navigation, which prevents the victim's session accompanying an attacker's link. Review this against any single sign-on or inbound-link flows into your backend first, as it also affects legitimate cross-site entry.

References

Credit to Awwader (@NRAwwad) for reporting the issue.

For more information

If you have any questions or comments about this advisory:

• Email us at hello@wintercms.com

Impact

Users with the backend.manage_branding ("Customize the back-end") or backend.manage_editor ("Manage global code editor preferences") permission can provide custom CSS through Settings → Customize Backend → Styles or Settings → Editor Settings → Markup Styles that is compiled through the LESS CSS parser and rendered on every backend page.

v1.2.13 addressed CVE-2026-32257 and CVE-2026-32258 by applying strip_tags() to the compiled output of BrandSetting::renderCss() and EditorSetting::renderCss(). That fix was incomplete. Both methods cache the raw compiler output with Cache::forever() and applied strip_tags() only to the value returned on a cache miss, so every subsequent cache hit returned the unsanitized value directly into the backend <style> element. The first page render after saving therefore appears sanitized while priming an unsafe cache entry, and the stored XSS remains exploitable from the second render onwards.

Because the custom styles partial is included by both the standard backend layout head and the backend authentication layout, an injected payload also renders on the unauthenticated backend sign-in, password restore, and password reset pages.

Although this is a valid security issue, it's important to note that its severity is relatively low. To exploit the vulnerability, an attacker would already need to have trusted access to the Winter CMS backend with a specific administrative permission. The Winter CMS maintainers recommend that the backend.manage_branding and backend.manage_editor permissions only be granted to trusted administrators and developers.

All users are advised to update to the latest version to ensure their systems remain secure.

Patches

This issue has been patched in v1.2.14. The renderCss() methods now apply strip_tags() to the cached value when it is read back, which also neutralizes any cache entry that was poisoned before upgrading.

The backend.manage_editor and backend.manage_default_dashboard permissions have additionally been given warning comments in the permission editor, matching the existing warning on backend.manage_branding.

Workarounds

Apply https://github.com/wintercms/winter/commit/c95d780ab54f3a3f74a94ae1667bf12b3c549d5d manually if unable to upgrade to v1.2.14.

Clearing the application cache removes an already-poisoned entry, but it will be recreated on the next backend page render unless the patch is applied.

References

• CVE-2026-32257 / GHSA-v7cf-8gh9-gxmj (Stored XSS through Brand Settings custom styles, incompletely patched in v1.2.13)
• CVE-2026-32258 / GHSA-vgp4-2fc4-qff2 (Stored XSS through Editor Settings custom styles, incompletely patched in v1.2.13)
• CVE-2025-61674 and CVE-2025-61676 (identical vulnerability in October CMS, patched in v3.7.13 and v4.0.12)

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.

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

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) for reporting the issue.

For more information

If you have any questions or comments about this advisory:

• Email us at hello@wintercms.com

Impact

Backend\Controllers\MyAccount, introduced in v1.2.13, declares an empty $requiredPermissions array so that any authenticated backend user can manage their own account. It implements the FormController behavior, which exposes three routable actions — create, update and preview — that each take a record id from the URL.

index() passes the authenticated user's own id to the behavior, but the inherited actions were left routable and formFindModelObject() was not scoped, so a caller-supplied id resolved against an unscoped Backend\Models\User query:

GET /backend/backend/myaccount/preview/{other_user_id}

preview disclosed the target user's first name, last name, login, email address and avatar; update was equally routable and additionally disclosed role, group membership, superuser flag and throttle state. Password controls render a mask, so no credential material was exposed. Backend user ids are sequential and trivially enumerated, and as these are GET actions no CSRF token is involved.

The behavior's AJAX handlers (create_onSave, update_onSave, update_onDelete) were also dispatchable on these routes, but cross-user writes were blocked by the Backend\Models\User authorization guards added in v1.2.13. The confirmed impact is unauthorized disclosure of backend user profile data.

To actively exploit this security issue, an attacker would need access to the Backend with a user account with any level of access.

Patches

MyAccount no longer exposes the generic record actions it never used as routes, and its form lookup is now pinned to the authenticated user:

• protected $guarded = ['create', 'update', 'preview']; removes the inherited actions from routing. The guard has to be at the routing layer, as handler dispatch ({action}_{handler}) runs before the page action.
• formExtendQuery() constrains every lookup made by the behavior to the current user's key.

This security issue has been fixed as of v1.2.14 (commit cdbc8f5a23db27f72ccec658a8e5769e6d9f6dcb).

Workarounds

There is no supported workaround other than upgrading. If you cannot upgrade immediately, you may apply the fix manually in modules/backend/controllers/MyAccount.php:

1. Add protected $guarded = ['create', 'update', 'preview']; to the controller.
2. Add a formExtendQuery() method that scopes the lookup to the current user:

public function formExtendQuery(\Winter\Storm\Database\Builder $query): void
{
    $query->whereKey($this->user->getKey());
}

References

• https://github.com/wintercms/winter/security/advisories/GHSA-j5jq-cr68-v2xx
• https://github.com/wintercms/winter/commit/cdbc8f5a23db27f72ccec658a8e5769e6d9f6dcb

Credit to Awwader (@NRAwwad) for reporting the issue.

For more information

If you have any questions or comments about this advisory:

• Email us at hello@wintercms.com

Impact

Backend\Widgets\Lists::evalImageTypeValue() interpolated the resolved image URL into a single-quoted src attribute without escaping it. Where a list column of type image rendered an attacker-influenced value, that value could break out of the attribute and inject arbitrary attributes — including event handlers — into the backend list, executing in the session of whichever backend user viewed it.

Winter core ships no image list column, so a default installation is unaffected. Exploitation requires a plugin that renders attacker-influenced values through one.

The supported image sources are plugins, themes, the Media Library, the uploads directory, and Attach\File models; an arbitrary external URL is not among them. ImageResizer::filterGetUrl() returns the value it was given when it cannot resolve an image, however, so an unsupported value reached the attribute verbatim rather than being rejected.

As with previous issues of this kind the severity is limited: an attacker must already be able to store the value, and a backend user must then open the affected list. Note that validating a stored URL was not necessarily sufficient — a payload can survive filter_var($url, FILTER_VALIDATE_URL), since / is valid both in a URL path and after a quoted HTML attribute value.

Patches

evalImageTypeValue() now escapes the image URL, along with the width and height taken from the column configuration, before interpolating them into the tag.

This security issue has been fixed as of v1.2.14 (commit 0941c9816181095fe35d58e78e6d0c4a49238967).

Workarounds

Apply the commit above to modules/backend/widgets/Lists.php manually if you are unable to upgrade to v1.2.14.

References

• https://github.com/wintercms/winter/security/advisories/GHSA-43w4-4j3c-jx29
• https://github.com/wintercms/winter/commit/0941c9816181095fe35d58e78e6d0c4a49238967

Credit to Seungyeon Park (@sy460129) for reporting the issue.

For more information

If you have any questions or comments about this advisory:

• Email us at hello@wintercms.com

Impact

Affected versions of Winter CMS render the search query parameter without HTML encoding inside a <script type="text/template"> block in the backend Table widget partial (modules/backend/widgets/table/partials/_table.php):

value="<?= get('search') ?>"

<script> is an HTML raw-text context, so the surrounding value="…" attribute quoting is not a parser boundary. A literal </script> in the query string terminates the template element early, and everything after it is parsed as ordinary markup in the backend document.

Any backend page rendering a Table or DataTable widget is a sink. The value is read from the global request through the get() helper, which — unlike post() — is not restricted by HTTP method, so a plain top-level GET navigation is sufficient. The template is also emitted unconditionally by the partial, so widgets using the default searching: false configuration are equally affected.

In Winter core the reachable route is the Editor Settings form (/backend/system/settings/update/winter/backend/editor), which renders six datatable fields and is gated by backend.manage_editor — assigned by default to the built-in Developer role. Third-party plugins using the datatable form widget, or the Table widget directly, expose the same sink on their own pages.

An attacker who induces a signed-in backend user to follow a crafted link executes script in that user's authenticated backend origin. The injected script can read the CSRF token published in the backend layout's <meta name="csrf-token"> element and issue credentialed requests as the victim, bounded only by that user's permissions. Because the core sink requires backend.manage_editor, the practical victim is a Developer-role user or superuser — who can edit CMS templates, so script running in that session can chain to server-side code execution.

This is not a permission bypass: the victim must already be authorised for the page, and the attacker gains no permission the victim does not hold.

To actively exploit this issue, an attacker needs no account of their own, but does need an authenticated backend user with access to a page rendering a Table or DataTable widget to follow an attacker-supplied link.

Patches

The search value is now HTML-encoded on output, matching every other value rendered by the same partial and the equivalent handling in the backend Search widget (modules/backend/widgets/search/partials/_search.php):

value="<?= e(get('search')); ?>"

This removes the raw-text terminator: the browser can no longer encounter an attacker-supplied literal </script> while tokenising the document. The template is subsequently parsed once by jQuery when the toolbar is built, so an encoded payload resolves to an inert attribute string rather than markup.

Regression coverage was added in modules/backend/tests/widgets/TableSearchEscapingTest.php, covering plain, mixed-case (</ScRiPt>) and whitespace-bearing (</script >) terminators, both searching states, and preservation of ordinary and Unicode search text.

This security issue has been fixed in v1.2.14.

Workarounds

If you cannot upgrade, apply https://github.com/wintercms/winter/commit/1b6397654124fb44a6abf6f3782b6a1d746cef14 manually — in modules/backend/widgets/table/partials/_table.php, change:

value="<?= get('search') ?>"

to:

value="<?= e(get('search')); ?>"

A restrictive Content Security Policy served at the web server or reverse proxy can reduce practical exploitability, but it is not a substitute for the fix: Winter's backend ships inline scripts, so a policy permissive enough to run the backend may still permit an injected execution primitive.

References

Credit to Awwader (@NRAwwad) for reporting the issue.

For more information

If you have any questions or comments about this advisory:

• Email us at hello@wintercms.com

Impact

Affected versions of Winter CMS allow a backend AJAX handler to be invoked by a plain top-level GET navigation with no CSRF token. Backend\Classes\Controller::actionExists() accepted any public method on a controller as a page action, so handler-shaped names were never reserved from URL dispatch: an authenticated and authorized request to /backend/system/eventlogs/index_onEmptyLog reached the handler of the same name and truncated the system event log. Backend paths are routed through Route::any, and CSRF validation is skipped for HEAD, GET and OPTIONS requests.

The default SameSite=Lax session cookie is sent on top-level cross-site navigation, so a link on an attacker-controlled page is sufficient — no form, no script and no token. Handler arguments are taken from URL path segments, so the attacker also chooses the target record. Affected handlers across the backend, cms and system modules cover log truncation, resetting settings to their defaults, altering backend user state, and deleting CMS templates. None of them disclose data to the attacker or write attacker-controlled content, so the impact is destructive and state-changing rather than confidential.

To actively exploit this issue, an attacker would need no account of their own, but would need an authenticated backend user holding the relevant permission to follow an attacker-supplied link. The permissions guarding the affected handlers, system.access_logs included, are by default assigned only to the built-in Developer role.

Patches

Page-action dispatch is now restricted to all-lowercase method names, which reserves handler-shaped names (onFoo, index_onFoo) from being reached by URL. AJAX dispatch is unchanged: handlers continue to work over POST with the X-WINTER-REQUEST-HANDLER header exactly as before, and need no changes.

IMPORTANT: This fix includes a breaking change to backend action routing. A public controller method used as a page action must now be named in lowercase — coming_soon() rather than comingSoon() — and dashed URLs are normalised to snake_case, so /coming-soon now resolves to coming_soon() instead of comingSoon(). Plugins with a camelCase page action should rename the method and its view file to match; the published URL does not need to change. Core is unaffected, and a survey of the plugin ecosystem found the change affects only a small number of plugins.

This security issue has been fixed in v1.2.14.

Workarounds

If you cannot upgrade, apply https://github.com/wintercms/winter/commit/353b23804dee2acf49fca996c72637040446824f manually.

As an interim mitigation, set 'same_site' => 'strict' in config/session.php. A strict session cookie is not sent on cross-site top-level navigation, which prevents the victim's session accompanying an attacker's link. Review this against any single sign-on or inbound-link flows into your backend first, as it also affects legitimate cross-site entry.

References

Credit to Awwader (@NRAwwad) for reporting the issue.

For more information

If you have any questions or comments about this advisory:

• Email us at hello@wintercms.com

Impact

Users with the backend.manage_branding ("Customize the back-end") or backend.manage_editor ("Manage global code editor preferences") permission can provide custom CSS through Settings → Customize Backend → Styles or Settings → Editor Settings → Markup Styles that is compiled through the LESS CSS parser and rendered on every backend page.

v1.2.13 addressed CVE-2026-32257 and CVE-2026-32258 by applying strip_tags() to the compiled output of BrandSetting::renderCss() and EditorSetting::renderCss(). That fix was incomplete. Both methods cache the raw compiler output with Cache::forever() and applied strip_tags() only to the value returned on a cache miss, so every subsequent cache hit returned the unsanitized value directly into the backend <style> element. The first page render after saving therefore appears sanitized while priming an unsafe cache entry, and the stored XSS remains exploitable from the second render onwards.

Because the custom styles partial is included by both the standard backend layout head and the backend authentication layout, an injected payload also renders on the unauthenticated backend sign-in, password restore, and password reset pages.

Although this is a valid security issue, it's important to note that its severity is relatively low. To exploit the vulnerability, an attacker would already need to have trusted access to the Winter CMS backend with a specific administrative permission. The Winter CMS maintainers recommend that the backend.manage_branding and backend.manage_editor permissions only be granted to trusted administrators and developers.

All users are advised to update to the latest version to ensure their systems remain secure.

Patches

This issue has been patched in v1.2.14. The renderCss() methods now apply strip_tags() to the cached value when it is read back, which also neutralizes any cache entry that was poisoned before upgrading.

The backend.manage_editor and backend.manage_default_dashboard permissions have additionally been given warning comments in the permission editor, matching the existing warning on backend.manage_branding.

Workarounds

Apply https://github.com/wintercms/winter/commit/c95d780ab54f3a3f74a94ae1667bf12b3c549d5d manually if unable to upgrade to v1.2.14.

Clearing the application cache removes an already-poisoned entry, but it will be recreated on the next backend page render unless the patch is applied.

References

• CVE-2026-32257 / GHSA-v7cf-8gh9-gxmj (Stored XSS through Brand Settings custom styles, incompletely patched in v1.2.13)
• CVE-2026-32258 / GHSA-vgp4-2fc4-qff2 (Stored XSS through Editor Settings custom styles, incompletely patched in v1.2.13)
• CVE-2025-61674 and CVE-2025-61676 (identical vulnerability in October CMS, patched in v3.7.13 and v4.0.12)

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.

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

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) for reporting the issue.

For more information

If you have any questions or comments about this advisory:

• Email us at hello@wintercms.com

Impact

Backend\Widgets\Lists::evalImageTypeValue() interpolated the resolved image URL into a single-quoted src attribute without escaping it. Where a list column of type image rendered an attacker-influenced value, that value could break out of the attribute and inject arbitrary attributes — including event handlers — into the backend list, executing in the session of whichever backend user viewed it.

Winter core ships no image list column, so a default installation is unaffected. Exploitation requires a plugin that renders attacker-influenced values through one.

The supported image sources are plugins, themes, the Media Library, the uploads directory, and Attach\File models; an arbitrary external URL is not among them. ImageResizer::filterGetUrl() returns the value it was given when it cannot resolve an image, however, so an unsupported value reached the attribute verbatim rather than being rejected.

As with previous issues of this kind the severity is limited: an attacker must already be able to store the value, and a backend user must then open the affected list. Note that validating a stored URL was not necessarily sufficient — a payload can survive filter_var($url, FILTER_VALIDATE_URL), since / is valid both in a URL path and after a quoted HTML attribute value.

Patches

evalImageTypeValue() now escapes the image URL, along with the width and height taken from the column configuration, before interpolating them into the tag.

This security issue has been fixed as of v1.2.14 (commit 0941c9816181095fe35d58e78e6d0c4a49238967).

Workarounds

Apply the commit above to modules/backend/widgets/Lists.php manually if you are unable to upgrade to v1.2.14.

References

• https://github.com/wintercms/winter/security/advisories/GHSA-43w4-4j3c-jx29
• https://github.com/wintercms/winter/commit/0941c9816181095fe35d58e78e6d0c4a49238967

Credit to Seungyeon Park (@sy460129) for reporting the issue.

For more information

If you have any questions or comments about this advisory:

• Email us at hello@wintercms.com

Impact

Affected versions of Winter CMS allow authenticated backend users with the following permissions to disclose arbitrary files readable by the PHP process by injecting @import (inline) "<path>" directives into LESS source that the backend compiles. Four entry points share the same root cause:

• Brand Settings BrandSetting.custom_css field (backend.manage_branding) — compiled inline into every backend page's <style> block.
• Editor Settings EditorSetting.html_custom_styles field (backend.manage_editor) — compiled inline into every backend page's <style> block.
• Mail Brand Settings MailBrandSetting colour-picker fields (system.manage_mail_templates) — values are concatenated into LESS source via Less_Parser::ModifyVars() with no escaping, so any value the form validator does not reject can carry an @import directive.
• Theme .less/.sass/.scss assets (cms.manage_assets) — compiled through System\Classes\CombineAssets when served, with the same Less_Parser configuration. Both absolute paths and .. traversal escape from the asset's own tree were exploitable.

The leaked content includes any file the web process can read, most importantly the application .env file (disclosing APP_KEY and database credentials).

To actively exploit this issue, an attacker would need an authenticated backend account with one of the permissions listed above. By default these are assigned to the built-in Developer role.

Patches

The root cause is in the wikimedia/less.php integration in Winter Storm: Less_Parser was instantiated without a safe import resolver, and its Less_FileManager::getFilePath() falls back to the raw attacker-supplied path when no candidate root matches. Storm now ships a LessImportResolver that uses the callable form of Less_Parser::SetImportDirs() to refuse any @import whose resolved path lies outside the calling context's allowed roots, defeating both absolute paths and .. traversal at the parser level.

The four sinks have been updated to use the resolver. The three settings models pass no allowed roots (deny-all) because the bundled stylesheets ship no @import directives and the user fields have no legitimate use for them. System\Classes\CombineAssets configures the theme-asset compiler with themes_path(), plugins_path(), and base_path('modules') as allowed roots, preserving real cross-tree imports observed in shipped themes and plugins.

This security issue has been fixed in v1.2.13 (Winter core) and v1.2.13 (Winter Storm).

Workarounds

If you cannot upgrade, apply https://github.com/wintercms/storm/commit/af770331c683e628533a6ec2991285d6e10a4d6c and https://github.com/wintercms/winter/commit/130f0ea43e9228bf0d129b481da1cdfbcc4b4456 manually. As an interim mitigation, remove cms.manage_assets from any non-trusted role and clear any non-empty value from the Brand Settings custom_css and Editor Settings html_custom_styles fields.

References

See https://github.com/octobercms/october/security/advisories/GHSA-3888-q23f-x7qh for the related (but distinct in scope) October CMS advisory addressing the theme-asset compiler path. The Brand/Editor/Mail Brand Settings sinks reported in this advisory are not covered by the October patch.

Credit to Nguyen Van Hiep (@hypnguyen1209) from Lo Security for reporting the issue.

For more information

If you have any questions or comments about this advisory:

• Email us at hello@wintercms.com

Impact

The backend FileUpload form widget trusted an attacker-controlled file_id POST parameter when resolving the attachment it operates on. The lookup (FileUpload::getFileRecord()) resolved the posted id against the global system_files table without verifying that the file belonged to the widget's own relation, parent record, or deferred-binding session.

Any authenticated backend user who can reach a form containing a fileupload field — including the built-in My Account avatar field, which requires no specific backend permission — could therefore target a System\Models\File record belonging to another user or record and:

• modify its title and description via onSaveAttachmentConfig, and
• change its sort_order via onSortAttachments (which passed posted ids straight to setSortableOrder(), an unscoped UPDATE ... WHERE id = ?).

The same unscoped lookup is reached by onLoadAttachmentConfig, onSaveAttachmentConfig, and onRemoveAttachment. Because all attachments share the single System\Models\File model and system_files table, an attacker was not limited to other users' avatars — any attachment on any model could be referenced by id. Attachment ids are sequential integers and are easily enumerated.

The confirmed impact is unauthorized integrity modification of arbitrary attachment metadata and ordering.

CSRF tokens are still verified on all POST requests, so an attacker must be authenticated to the backend with a valid session. To exploit this issue an attacker needs a backend account with any level of access.

Patches

The FileUpload widget now scopes every file_id lookup to the widget's own relation, including any files bound through the current deferred-binding session, so a posted id can no longer reference an unrelated System\Models\File record:

• getFileRecord() resolves the id through getRelationObject()->withDeferred($this->sessionKey)->find(...) rather than the global file model. This covers onLoadAttachmentConfig, onSaveAttachmentConfig, and onRemoveAttachment.
• onSortAttachments() intersects the posted ids with the ids that actually belong to the relation before calling setSortableOrder().

This security issue has been fixed as of v1.2.13 (commit 9cb0ae5f9d837db141ab111c6a7de8eed9603d25).

Workarounds

There is no supported workaround other than upgrading. If you cannot upgrade immediately, you may apply the fix manually in modules/backend/formwidgets/FileUpload.php:

1. In getFileRecord(), replace $this->getRelationModel()->find(post('file_id')) with $this->getRelationObject()->withDeferred($this->sessionKey)->find(post('file_id')).
2. In onSortAttachments(), filter the posted sortOrder ids to those returned by $this->getRelationObject()->withDeferred($this->sessionKey)->pluck($keyName) before calling setSortableOrder().

Impact

Affected versions of Winter CMS did not validate the handler name submitted through the form postback mechanism (_handler POST field) in the same way as AJAX requests (X_WINTER_REQUEST_HANDLER header). The AJAX path validates that handler names match the on[A-Z][\w+]* pattern, but the postback path passed the handler name directly to the handler dispatcher with no validation.

This allowed an authenticated backend user to call any method on a controller — including action-prefixed, protected, and private methods — by submitting a crafted POST request with a _handler field, as long as the controller either:

• Contains a publicly available action via the $publicActions property, or
• Degrades or removes the $requiredPermissions check in its constructor based on a condition

The backend's own Users controller was affected by the second scenario: it set $requiredPermissions to null for the myaccount action, allowing any authenticated backend user to access the controller without the backend.manage_users permission. Combined with the postback bypass, this allowed calling controller methods such as update_onDelete, update_onRestore, update_onUnsuspendUser, and update_onManualPasswordReset with attacker-controlled parameters.

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 security issue, an attacker would need access to the Backend with a user account with any level of access.

The Winter CMS maintainers strongly recommend that all Winter CMS sites that have any reliance on the roles & permissions system to update immediately. Security fixes have been backported to all major versions of Winter (1.0, 1.1, and 1.2).

Patches

The postback handler path now validates handler names using the same rules as the AJAX path. The My Account functionality has been moved to a dedicated controller that does not expose user management methods. Defence in depth has been applied at the model level to prevent unauthorized user record modifications regardless of the entry point.

This security issue has been fixed as of v1.2.13.

Workarounds

If users cannot upgrade, they may apply the following changes to their Winter CMS installation manually to resolve this issue:

1. In modules/backend/classes/Controller.php, validate the _handler POST field against the on[A-Z][\w+]* pattern before passing it to runAjaxHandler().
2. In modules/backend/controllers/Users.php, remove the conditional that sets $requiredPermissions to null for the myaccount action.

Impact

The Backend Filter widget (Backend\Widgets\Filter) is vulnerable to SQL injection through the numberrange scope type when the scope is configured with a conditions key. An authenticated backend user with access to a list view containing a vulnerable filter scope can inject arbitrary SQL via the filter's AJAX handler, potentially gaining read access to the full database contents.

To exploit this, an attacker must have a valid backend account with access to a list view where a third-party plugin has registered a numberrange filter scope using the conditions configuration key. No built-in Winter CMS backend views use this scope type and configuration combination, so a vanilla installation without plugins is not exploitable.

Patches

This issue has been fixed in Winter CMS v1.2.13.

Workarounds

If users cannot upgrade, they may apply commit https://github.com/wintercms/winter/commit/50713de95adf5298536d93f4d999652525d36d43 to your Winter CMS installation manually to resolve this issue.

Impact

Authenticated Backend Users with the backend.manage_editor ("Manage editor settings") permission can provide custom styles through Settings → Editor Settings → Markup Styles that are compiled through the LESS CSS parser and rendered on every backend page. Previously, the compiled output was not sanitized, which could have allowed a stored XSS attack.

Although this is a valid security issue, it's important to note that its severity is relatively low. To exploit the vulnerability, an attacker would already need to have trusted access to the Winter CMS backend with a specific administrative permission. The Winter CMS maintainers recommend that the backend.manage_editor permission only be granted to trusted administrators and developers.

A related issue exists in the custom CSS field at Settings → Customize Backend → Styles (backend.manage_branding permission), which uses the same rendering mechanism and is addressed separately.

All users are advised to update to the latest version to ensure their systems remain secure.

Patches

This issue has been patched in v1.2.13. The renderCss() method now applies strip_tags() to compiled CSS output before returning it.

Workarounds

Apply https://github.com/wintercms/winter/commit/d28f0b9474af79cfaa80eeb9d691f7a7c4469720 manually if unable to upgrade to v1.2.13.

Resources

• CVE-2025-61674 (identical vulnerability in October CMS, patched in v3.7.13 and v4.0.12)

Impact

Users with the backend.manage_branding ("Customize the back-end") permission can provide custom CSS through Settings → Customize Backend → Styles that is compiled through the LESS CSS parser and rendered on every backend page. Previously, the compiled output was not sanitized, which could have allowed a stored XSS attack.

Although this is a valid security issue, it's important to note that its severity is relatively low. To exploit the vulnerability, an attacker would already need to have trusted access to the Winter CMS backend with a specific administrative permission. The Winter CMS maintainers recommend that the backend.manage_branding permission only be granted to trusted administrators and developers.

A related issue exists in the custom styles field at Settings → Editor Settings → Markup Styles (backend.manage_editor permission), which uses the same rendering mechanism and is addressed separately.

All users are advised to update to the latest version to ensure their systems remain secure.

Patches

This issue has been patched in v1.2.13.

Workarounds

Apply https://github.com/wintercms/winter/commit/d28f0b9474af79cfaa80eeb9d691f7a7c4469720 manually if unable to upgrade to v1.2.13.

Resources

• CVE-2025-61676 (identical vulnerability in October CMS, patched in v3.7.13 and v4.0.12)

Impact

Affected versions of Winter CMS render the search query parameter without HTML encoding inside a <script type="text/template"> block in the backend Table widget partial (modules/backend/widgets/table/partials/_table.php):

value="<?= get('search') ?>"

<script> is an HTML raw-text context, so the surrounding value="…" attribute quoting is not a parser boundary. A literal </script> in the query string terminates the template element early, and everything after it is parsed as ordinary markup in the backend document.

Any backend page rendering a Table or DataTable widget is a sink. The value is read from the global request through the get() helper, which — unlike post() — is not restricted by HTTP method, so a plain top-level GET navigation is sufficient. The template is also emitted unconditionally by the partial, so widgets using the default searching: false configuration are equally affected.

In Winter core the reachable route is the Editor Settings form (/backend/system/settings/update/winter/backend/editor), which renders six datatable fields and is gated by backend.manage_editor — assigned by default to the built-in Developer role. Third-party plugins using the datatable form widget, or the Table widget directly, expose the same sink on their own pages.

An attacker who induces a signed-in backend user to follow a crafted link executes script in that user's authenticated backend origin. The injected script can read the CSRF token published in the backend layout's <meta name="csrf-token"> element and issue credentialed requests as the victim, bounded only by that user's permissions. Because the core sink requires backend.manage_editor, the practical victim is a Developer-role user or superuser — who can edit CMS templates, so script running in that session can chain to server-side code execution.

This is not a permission bypass: the victim must already be authorised for the page, and the attacker gains no permission the victim does not hold.

To actively exploit this issue, an attacker needs no account of their own, but does need an authenticated backend user with access to a page rendering a Table or DataTable widget to follow an attacker-supplied link.

Patches

The search value is now HTML-encoded on output, matching every other value rendered by the same partial and the equivalent handling in the backend Search widget (modules/backend/widgets/search/partials/_search.php):

value="<?= e(get('search')); ?>"

This removes the raw-text terminator: the browser can no longer encounter an attacker-supplied literal </script> while tokenising the document. The template is subsequently parsed once by jQuery when the toolbar is built, so an encoded payload resolves to an inert attribute string rather than markup.

Regression coverage was added in modules/backend/tests/widgets/TableSearchEscapingTest.php, covering plain, mixed-case (</ScRiPt>) and whitespace-bearing (</script >) terminators, both searching states, and preservation of ordinary and Unicode search text.

This security issue has been fixed in v1.2.14.

Workarounds

If you cannot upgrade, apply https://github.com/wintercms/winter/commit/1b6397654124fb44a6abf6f3782b6a1d746cef14 manually — in modules/backend/widgets/table/partials/_table.php, change:

value="<?= get('search') ?>"

to:

value="<?= e(get('search')); ?>"

A restrictive Content Security Policy served at the web server or reverse proxy can reduce practical exploitability, but it is not a substitute for the fix: Winter's backend ships inline scripts, so a policy permissive enough to run the backend may still permit an injected execution primitive.

References

Credit to Awwader (@NRAwwad) for reporting the issue.

For more information

If you have any questions or comments about this advisory:

• Email us at hello@wintercms.com

Impact

Affected versions of Winter CMS allow a backend AJAX handler to be invoked by a plain top-level GET navigation with no CSRF token. Backend\Classes\Controller::actionExists() accepted any public method on a controller as a page action, so handler-shaped names were never reserved from URL dispatch: an authenticated and authorized request to /backend/system/eventlogs/index_onEmptyLog reached the handler of the same name and truncated the system event log. Backend paths are routed through Route::any, and CSRF validation is skipped for HEAD, GET and OPTIONS requests.

The default SameSite=Lax session cookie is sent on top-level cross-site navigation, so a link on an attacker-controlled page is sufficient — no form, no script and no token. Handler arguments are taken from URL path segments, so the attacker also chooses the target record. Affected handlers across the backend, cms and system modules cover log truncation, resetting settings to their defaults, altering backend user state, and deleting CMS templates. None of them disclose data to the attacker or write attacker-controlled content, so the impact is destructive and state-changing rather than confidential.

To actively exploit this issue, an attacker would need no account of their own, but would need an authenticated backend user holding the relevant permission to follow an attacker-supplied link. The permissions guarding the affected handlers, system.access_logs included, are by default assigned only to the built-in Developer role.

Patches

Page-action dispatch is now restricted to all-lowercase method names, which reserves handler-shaped names (onFoo, index_onFoo) from being reached by URL. AJAX dispatch is unchanged: handlers continue to work over POST with the X-WINTER-REQUEST-HANDLER header exactly as before, and need no changes.

IMPORTANT: This fix includes a breaking change to backend action routing. A public controller method used as a page action must now be named in lowercase — coming_soon() rather than comingSoon() — and dashed URLs are normalised to snake_case, so /coming-soon now resolves to coming_soon() instead of comingSoon(). Plugins with a camelCase page action should rename the method and its view file to match; the published URL does not need to change. Core is unaffected, and a survey of the plugin ecosystem found the change affects only a small number of plugins.

This security issue has been fixed in v1.2.14.

Workarounds

If you cannot upgrade, apply https://github.com/wintercms/winter/commit/353b23804dee2acf49fca996c72637040446824f manually.

As an interim mitigation, set 'same_site' => 'strict' in config/session.php. A strict session cookie is not sent on cross-site top-level navigation, which prevents the victim's session accompanying an attacker's link. Review this against any single sign-on or inbound-link flows into your backend first, as it also affects legitimate cross-site entry.

References

Credit to Awwader (@NRAwwad) for reporting the issue.

For more information

If you have any questions or comments about this advisory:

• Email us at hello@wintercms.com

Impact

Users with the backend.manage_branding ("Customize the back-end") or backend.manage_editor ("Manage global code editor preferences") permission can provide custom CSS through Settings → Customize Backend → Styles or Settings → Editor Settings → Markup Styles that is compiled through the LESS CSS parser and rendered on every backend page.

v1.2.13 addressed CVE-2026-32257 and CVE-2026-32258 by applying strip_tags() to the compiled output of BrandSetting::renderCss() and EditorSetting::renderCss(). That fix was incomplete. Both methods cache the raw compiler output with Cache::forever() and applied strip_tags() only to the value returned on a cache miss, so every subsequent cache hit returned the unsanitized value directly into the backend <style> element. The first page render after saving therefore appears sanitized while priming an unsafe cache entry, and the stored XSS remains exploitable from the second render onwards.

Because the custom styles partial is included by both the standard backend layout head and the backend authentication layout, an injected payload also renders on the unauthenticated backend sign-in, password restore, and password reset pages.

Although this is a valid security issue, it's important to note that its severity is relatively low. To exploit the vulnerability, an attacker would already need to have trusted access to the Winter CMS backend with a specific administrative permission. The Winter CMS maintainers recommend that the backend.manage_branding and backend.manage_editor permissions only be granted to trusted administrators and developers.

All users are advised to update to the latest version to ensure their systems remain secure.

Patches

This issue has been patched in v1.2.14. The renderCss() methods now apply strip_tags() to the cached value when it is read back, which also neutralizes any cache entry that was poisoned before upgrading.

The backend.manage_editor and backend.manage_default_dashboard permissions have additionally been given warning comments in the permission editor, matching the existing warning on backend.manage_branding.

Workarounds

Apply https://github.com/wintercms/winter/commit/c95d780ab54f3a3f74a94ae1667bf12b3c549d5d manually if unable to upgrade to v1.2.14.

Clearing the application cache removes an already-poisoned entry, but it will be recreated on the next backend page render unless the patch is applied.

References

• CVE-2026-32257 / GHSA-v7cf-8gh9-gxmj (Stored XSS through Brand Settings custom styles, incompletely patched in v1.2.13)
• CVE-2026-32258 / GHSA-vgp4-2fc4-qff2 (Stored XSS through Editor Settings custom styles, incompletely patched in v1.2.13)
• CVE-2025-61674 and CVE-2025-61676 (identical vulnerability in October CMS, patched in v3.7.13 and v4.0.12)

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.

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

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) for reporting the issue.

For more information

If you have any questions or comments about this advisory:

• Email us at hello@wintercms.com

Impact

Backend\Widgets\Lists::evalImageTypeValue() interpolated the resolved image URL into a single-quoted src attribute without escaping it. Where a list column of type image rendered an attacker-influenced value, that value could break out of the attribute and inject arbitrary attributes — including event handlers — into the backend list, executing in the session of whichever backend user viewed it.

Winter core ships no image list column, so a default installation is unaffected. Exploitation requires a plugin that renders attacker-influenced values through one.

The supported image sources are plugins, themes, the Media Library, the uploads directory, and Attach\File models; an arbitrary external URL is not among them. ImageResizer::filterGetUrl() returns the value it was given when it cannot resolve an image, however, so an unsupported value reached the attribute verbatim rather than being rejected.

As with previous issues of this kind the severity is limited: an attacker must already be able to store the value, and a backend user must then open the affected list. Note that validating a stored URL was not necessarily sufficient — a payload can survive filter_var($url, FILTER_VALIDATE_URL), since / is valid both in a URL path and after a quoted HTML attribute value.

Patches

evalImageTypeValue() now escapes the image URL, along with the width and height taken from the column configuration, before interpolating them into the tag.

This security issue has been fixed as of v1.2.14 (commit 0941c9816181095fe35d58e78e6d0c4a49238967).

Workarounds

Apply the commit above to modules/backend/widgets/Lists.php manually if you are unable to upgrade to v1.2.14.

References

• https://github.com/wintercms/winter/security/advisories/GHSA-43w4-4j3c-jx29
• https://github.com/wintercms/winter/commit/0941c9816181095fe35d58e78e6d0c4a49238967

Credit to Seungyeon Park (@sy460129) for reporting the issue.

For more information

If you have any questions or comments about this advisory:

• Email us at hello@wintercms.com

Impact

Affected versions of Winter CMS allow authenticated backend users with the following permissions to disclose arbitrary files readable by the PHP process by injecting @import (inline) "<path>" directives into LESS source that the backend compiles. Four entry points share the same root cause:

• Brand Settings BrandSetting.custom_css field (backend.manage_branding) — compiled inline into every backend page's <style> block.
• Editor Settings EditorSetting.html_custom_styles field (backend.manage_editor) — compiled inline into every backend page's <style> block.
• Mail Brand Settings MailBrandSetting colour-picker fields (system.manage_mail_templates) — values are concatenated into LESS source via Less_Parser::ModifyVars() with no escaping, so any value the form validator does not reject can carry an @import directive.
• Theme .less/.sass/.scss assets (cms.manage_assets) — compiled through System\Classes\CombineAssets when served, with the same Less_Parser configuration. Both absolute paths and .. traversal escape from the asset's own tree were exploitable.

The leaked content includes any file the web process can read, most importantly the application .env file (disclosing APP_KEY and database credentials).

To actively exploit this issue, an attacker would need an authenticated backend account with one of the permissions listed above. By default these are assigned to the built-in Developer role.

Patches

The root cause is in the wikimedia/less.php integration in Winter Storm: Less_Parser was instantiated without a safe import resolver, and its Less_FileManager::getFilePath() falls back to the raw attacker-supplied path when no candidate root matches. Storm now ships a LessImportResolver that uses the callable form of Less_Parser::SetImportDirs() to refuse any @import whose resolved path lies outside the calling context's allowed roots, defeating both absolute paths and .. traversal at the parser level.

The four sinks have been updated to use the resolver. The three settings models pass no allowed roots (deny-all) because the bundled stylesheets ship no @import directives and the user fields have no legitimate use for them. System\Classes\CombineAssets configures the theme-asset compiler with themes_path(), plugins_path(), and base_path('modules') as allowed roots, preserving real cross-tree imports observed in shipped themes and plugins.

This security issue has been fixed in v1.2.13 (Winter core) and v1.2.13 (Winter Storm).

Workarounds

If you cannot upgrade, apply https://github.com/wintercms/storm/commit/af770331c683e628533a6ec2991285d6e10a4d6c and https://github.com/wintercms/winter/commit/130f0ea43e9228bf0d129b481da1cdfbcc4b4456 manually. As an interim mitigation, remove cms.manage_assets from any non-trusted role and clear any non-empty value from the Brand Settings custom_css and Editor Settings html_custom_styles fields.

References

See https://github.com/octobercms/october/security/advisories/GHSA-3888-q23f-x7qh for the related (but distinct in scope) October CMS advisory addressing the theme-asset compiler path. The Brand/Editor/Mail Brand Settings sinks reported in this advisory are not covered by the October patch.

Credit to Nguyen Van Hiep (@hypnguyen1209) from Lo Security for reporting the issue.

For more information

If you have any questions or comments about this advisory:

• Email us at hello@wintercms.com

Impact

The backend FileUpload form widget trusted an attacker-controlled file_id POST parameter when resolving the attachment it operates on. The lookup (FileUpload::getFileRecord()) resolved the posted id against the global system_files table without verifying that the file belonged to the widget's own relation, parent record, or deferred-binding session.

Any authenticated backend user who can reach a form containing a fileupload field — including the built-in My Account avatar field, which requires no specific backend permission — could therefore target a System\Models\File record belonging to another user or record and:

• modify its title and description via onSaveAttachmentConfig, and
• change its sort_order via onSortAttachments (which passed posted ids straight to setSortableOrder(), an unscoped UPDATE ... WHERE id = ?).

The same unscoped lookup is reached by onLoadAttachmentConfig, onSaveAttachmentConfig, and onRemoveAttachment. Because all attachments share the single System\Models\File model and system_files table, an attacker was not limited to other users' avatars — any attachment on any model could be referenced by id. Attachment ids are sequential integers and are easily enumerated.

The confirmed impact is unauthorized integrity modification of arbitrary attachment metadata and ordering.

CSRF tokens are still verified on all POST requests, so an attacker must be authenticated to the backend with a valid session. To exploit this issue an attacker needs a backend account with any level of access.

Patches

The FileUpload widget now scopes every file_id lookup to the widget's own relation, including any files bound through the current deferred-binding session, so a posted id can no longer reference an unrelated System\Models\File record:

• getFileRecord() resolves the id through getRelationObject()->withDeferred($this->sessionKey)->find(...) rather than the global file model. This covers onLoadAttachmentConfig, onSaveAttachmentConfig, and onRemoveAttachment.
• onSortAttachments() intersects the posted ids with the ids that actually belong to the relation before calling setSortableOrder().

This security issue has been fixed as of v1.2.13 (commit 9cb0ae5f9d837db141ab111c6a7de8eed9603d25).

Workarounds

There is no supported workaround other than upgrading. If you cannot upgrade immediately, you may apply the fix manually in modules/backend/formwidgets/FileUpload.php:

1. In getFileRecord(), replace $this->getRelationModel()->find(post('file_id')) with $this->getRelationObject()->withDeferred($this->sessionKey)->find(post('file_id')).
2. In onSortAttachments(), filter the posted sortOrder ids to those returned by $this->getRelationObject()->withDeferred($this->sessionKey)->pluck($keyName) before calling setSortableOrder().

Impact

Affected versions of Winter CMS did not validate the handler name submitted through the form postback mechanism (_handler POST field) in the same way as AJAX requests (X_WINTER_REQUEST_HANDLER header). The AJAX path validates that handler names match the on[A-Z][\w+]* pattern, but the postback path passed the handler name directly to the handler dispatcher with no validation.

This allowed an authenticated backend user to call any method on a controller — including action-prefixed, protected, and private methods — by submitting a crafted POST request with a _handler field, as long as the controller either:

• Contains a publicly available action via the $publicActions property, or
• Degrades or removes the $requiredPermissions check in its constructor based on a condition

The backend's own Users controller was affected by the second scenario: it set $requiredPermissions to null for the myaccount action, allowing any authenticated backend user to access the controller without the backend.manage_users permission. Combined with the postback bypass, this allowed calling controller methods such as update_onDelete, update_onRestore, update_onUnsuspendUser, and update_onManualPasswordReset with attacker-controlled parameters.

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 security issue, an attacker would need access to the Backend with a user account with any level of access.

The Winter CMS maintainers strongly recommend that all Winter CMS sites that have any reliance on the roles & permissions system to update immediately. Security fixes have been backported to all major versions of Winter (1.0, 1.1, and 1.2).

Patches

The postback handler path now validates handler names using the same rules as the AJAX path. The My Account functionality has been moved to a dedicated controller that does not expose user management methods. Defence in depth has been applied at the model level to prevent unauthorized user record modifications regardless of the entry point.

This security issue has been fixed as of v1.2.13.

Workarounds

If users cannot upgrade, they may apply the following changes to their Winter CMS installation manually to resolve this issue:

1. In modules/backend/classes/Controller.php, validate the _handler POST field against the on[A-Z][\w+]* pattern before passing it to runAjaxHandler().
2. In modules/backend/controllers/Users.php, remove the conditional that sets $requiredPermissions to null for the myaccount action.

Impact

The Backend Filter widget (Backend\Widgets\Filter) is vulnerable to SQL injection through the numberrange scope type when the scope is configured with a conditions key. An authenticated backend user with access to a list view containing a vulnerable filter scope can inject arbitrary SQL via the filter's AJAX handler, potentially gaining read access to the full database contents.

To exploit this, an attacker must have a valid backend account with access to a list view where a third-party plugin has registered a numberrange filter scope using the conditions configuration key. No built-in Winter CMS backend views use this scope type and configuration combination, so a vanilla installation without plugins is not exploitable.

Patches

This issue has been fixed in Winter CMS v1.2.13.

Workarounds

If users cannot upgrade, they may apply commit https://github.com/wintercms/winter/commit/50713de95adf5298536d93f4d999652525d36d43 to your Winter CMS installation manually to resolve this issue.

Impact

Authenticated Backend Users with the backend.manage_editor ("Manage editor settings") permission can provide custom styles through Settings → Editor Settings → Markup Styles that are compiled through the LESS CSS parser and rendered on every backend page. Previously, the compiled output was not sanitized, which could have allowed a stored XSS attack.

Although this is a valid security issue, it's important to note that its severity is relatively low. To exploit the vulnerability, an attacker would already need to have trusted access to the Winter CMS backend with a specific administrative permission. The Winter CMS maintainers recommend that the backend.manage_editor permission only be granted to trusted administrators and developers.

A related issue exists in the custom CSS field at Settings → Customize Backend → Styles (backend.manage_branding permission), which uses the same rendering mechanism and is addressed separately.

All users are advised to update to the latest version to ensure their systems remain secure.

Patches

This issue has been patched in v1.2.13. The renderCss() method now applies strip_tags() to compiled CSS output before returning it.

Workarounds

Apply https://github.com/wintercms/winter/commit/d28f0b9474af79cfaa80eeb9d691f7a7c4469720 manually if unable to upgrade to v1.2.13.

Resources

• CVE-2025-61674 (identical vulnerability in October CMS, patched in v3.7.13 and v4.0.12)

Impact

Users with the backend.manage_branding ("Customize the back-end") permission can provide custom CSS through Settings → Customize Backend → Styles that is compiled through the LESS CSS parser and rendered on every backend page. Previously, the compiled output was not sanitized, which could have allowed a stored XSS attack.

Although this is a valid security issue, it's important to note that its severity is relatively low. To exploit the vulnerability, an attacker would already need to have trusted access to the Winter CMS backend with a specific administrative permission. The Winter CMS maintainers recommend that the backend.manage_branding permission only be granted to trusted administrators and developers.

A related issue exists in the custom styles field at Settings → Editor Settings → Markup Styles (backend.manage_editor permission), which uses the same rendering mechanism and is addressed separately.

All users are advised to update to the latest version to ensure their systems remain secure.

Patches

This issue has been patched in v1.2.13.

Workarounds

Apply https://github.com/wintercms/winter/commit/d28f0b9474af79cfaa80eeb9d691f7a7c4469720 manually if unable to upgrade to v1.2.13.

Resources

• CVE-2025-61676 (identical vulnerability in October CMS, patched in v3.7.13 and v4.0.12)

Impact

Affected versions of Winter CMS allowed authenticated backend users to escalate their accounts level of access to the system by modifying the roles / permissions assigned to their account through specially crafted requests to the backend while logged in.

To actively exploit this security issue, an attacker would need access to the Backend with a user account with any level of access.

The Winter CMS maintainers strongly recommend that all Winter CMS sites that have any reliance on the roles & permissions system to update immediately. Security fixes have been backported to all major versions of Winter (1.0, 1.1, and 1.2).

Patches

Multiple fixes and defence in depth has been applied to prevent current and future privilege escalation attacks at the lowest level possible.

This security issue has been fixed as of https://wintercms.com/releases/v1.0.477, https://wintercms.com/releases/v1.1.12, https://wintercms.com/releases/v1.2.12.

Workarounds

If you cannot upgrade, you may apply the changes from the releases to your Winter CMS installation manually to resolve this issue.

Impact

Affected versions of Winter CMS render the search query parameter without HTML encoding inside a <script type="text/template"> block in the backend Table widget partial (modules/backend/widgets/table/partials/_table.php):

value="<?= get('search') ?>"

<script> is an HTML raw-text context, so the surrounding value="…" attribute quoting is not a parser boundary. A literal </script> in the query string terminates the template element early, and everything after it is parsed as ordinary markup in the backend document.

Any backend page rendering a Table or DataTable widget is a sink. The value is read from the global request through the get() helper, which — unlike post() — is not restricted by HTTP method, so a plain top-level GET navigation is sufficient. The template is also emitted unconditionally by the partial, so widgets using the default searching: false configuration are equally affected.

In Winter core the reachable route is the Editor Settings form (/backend/system/settings/update/winter/backend/editor), which renders six datatable fields and is gated by backend.manage_editor — assigned by default to the built-in Developer role. Third-party plugins using the datatable form widget, or the Table widget directly, expose the same sink on their own pages.

An attacker who induces a signed-in backend user to follow a crafted link executes script in that user's authenticated backend origin. The injected script can read the CSRF token published in the backend layout's <meta name="csrf-token"> element and issue credentialed requests as the victim, bounded only by that user's permissions. Because the core sink requires backend.manage_editor, the practical victim is a Developer-role user or superuser — who can edit CMS templates, so script running in that session can chain to server-side code execution.

This is not a permission bypass: the victim must already be authorised for the page, and the attacker gains no permission the victim does not hold.

To actively exploit this issue, an attacker needs no account of their own, but does need an authenticated backend user with access to a page rendering a Table or DataTable widget to follow an attacker-supplied link.

Patches

The search value is now HTML-encoded on output, matching every other value rendered by the same partial and the equivalent handling in the backend Search widget (modules/backend/widgets/search/partials/_search.php):

value="<?= e(get('search')); ?>"

This removes the raw-text terminator: the browser can no longer encounter an attacker-supplied literal </script> while tokenising the document. The template is subsequently parsed once by jQuery when the toolbar is built, so an encoded payload resolves to an inert attribute string rather than markup.

Regression coverage was added in modules/backend/tests/widgets/TableSearchEscapingTest.php, covering plain, mixed-case (</ScRiPt>) and whitespace-bearing (</script >) terminators, both searching states, and preservation of ordinary and Unicode search text.

This security issue has been fixed in v1.2.14.

Workarounds

If you cannot upgrade, apply https://github.com/wintercms/winter/commit/1b6397654124fb44a6abf6f3782b6a1d746cef14 manually — in modules/backend/widgets/table/partials/_table.php, change:

value="<?= get('search') ?>"

to:

value="<?= e(get('search')); ?>"

A restrictive Content Security Policy served at the web server or reverse proxy can reduce practical exploitability, but it is not a substitute for the fix: Winter's backend ships inline scripts, so a policy permissive enough to run the backend may still permit an injected execution primitive.

References

Credit to Awwader (@NRAwwad) for reporting the issue.

For more information

If you have any questions or comments about this advisory:

• Email us at hello@wintercms.com

Impact

Affected versions of Winter CMS allow a backend AJAX handler to be invoked by a plain top-level GET navigation with no CSRF token. Backend\Classes\Controller::actionExists() accepted any public method on a controller as a page action, so handler-shaped names were never reserved from URL dispatch: an authenticated and authorized request to /backend/system/eventlogs/index_onEmptyLog reached the handler of the same name and truncated the system event log. Backend paths are routed through Route::any, and CSRF validation is skipped for HEAD, GET and OPTIONS requests.

The default SameSite=Lax session cookie is sent on top-level cross-site navigation, so a link on an attacker-controlled page is sufficient — no form, no script and no token. Handler arguments are taken from URL path segments, so the attacker also chooses the target record. Affected handlers across the backend, cms and system modules cover log truncation, resetting settings to their defaults, altering backend user state, and deleting CMS templates. None of them disclose data to the attacker or write attacker-controlled content, so the impact is destructive and state-changing rather than confidential.

To actively exploit this issue, an attacker would need no account of their own, but would need an authenticated backend user holding the relevant permission to follow an attacker-supplied link. The permissions guarding the affected handlers, system.access_logs included, are by default assigned only to the built-in Developer role.

Patches

Page-action dispatch is now restricted to all-lowercase method names, which reserves handler-shaped names (onFoo, index_onFoo) from being reached by URL. AJAX dispatch is unchanged: handlers continue to work over POST with the X-WINTER-REQUEST-HANDLER header exactly as before, and need no changes.

IMPORTANT: This fix includes a breaking change to backend action routing. A public controller method used as a page action must now be named in lowercase — coming_soon() rather than comingSoon() — and dashed URLs are normalised to snake_case, so /coming-soon now resolves to coming_soon() instead of comingSoon(). Plugins with a camelCase page action should rename the method and its view file to match; the published URL does not need to change. Core is unaffected, and a survey of the plugin ecosystem found the change affects only a small number of plugins.

This security issue has been fixed in v1.2.14.

Workarounds

If you cannot upgrade, apply https://github.com/wintercms/winter/commit/353b23804dee2acf49fca996c72637040446824f manually.

As an interim mitigation, set 'same_site' => 'strict' in config/session.php. A strict session cookie is not sent on cross-site top-level navigation, which prevents the victim's session accompanying an attacker's link. Review this against any single sign-on or inbound-link flows into your backend first, as it also affects legitimate cross-site entry.

References

Credit to Awwader (@NRAwwad) for reporting the issue.

For more information

If you have any questions or comments about this advisory:

• Email us at hello@wintercms.com

Impact

Users with the backend.manage_branding ("Customize the back-end") or backend.manage_editor ("Manage global code editor preferences") permission can provide custom CSS through Settings → Customize Backend → Styles or Settings → Editor Settings → Markup Styles that is compiled through the LESS CSS parser and rendered on every backend page.

v1.2.13 addressed CVE-2026-32257 and CVE-2026-32258 by applying strip_tags() to the compiled output of BrandSetting::renderCss() and EditorSetting::renderCss(). That fix was incomplete. Both methods cache the raw compiler output with Cache::forever() and applied strip_tags() only to the value returned on a cache miss, so every subsequent cache hit returned the unsanitized value directly into the backend <style> element. The first page render after saving therefore appears sanitized while priming an unsafe cache entry, and the stored XSS remains exploitable from the second render onwards.

Because the custom styles partial is included by both the standard backend layout head and the backend authentication layout, an injected payload also renders on the unauthenticated backend sign-in, password restore, and password reset pages.

Although this is a valid security issue, it's important to note that its severity is relatively low. To exploit the vulnerability, an attacker would already need to have trusted access to the Winter CMS backend with a specific administrative permission. The Winter CMS maintainers recommend that the backend.manage_branding and backend.manage_editor permissions only be granted to trusted administrators and developers.

All users are advised to update to the latest version to ensure their systems remain secure.

Patches

This issue has been patched in v1.2.14. The renderCss() methods now apply strip_tags() to the cached value when it is read back, which also neutralizes any cache entry that was poisoned before upgrading.

The backend.manage_editor and backend.manage_default_dashboard permissions have additionally been given warning comments in the permission editor, matching the existing warning on backend.manage_branding.

Workarounds

Apply https://github.com/wintercms/winter/commit/c95d780ab54f3a3f74a94ae1667bf12b3c549d5d manually if unable to upgrade to v1.2.14.

Clearing the application cache removes an already-poisoned entry, but it will be recreated on the next backend page render unless the patch is applied.

References

• CVE-2026-32257 / GHSA-v7cf-8gh9-gxmj (Stored XSS through Brand Settings custom styles, incompletely patched in v1.2.13)
• CVE-2026-32258 / GHSA-vgp4-2fc4-qff2 (Stored XSS through Editor Settings custom styles, incompletely patched in v1.2.13)
• CVE-2025-61674 and CVE-2025-61676 (identical vulnerability in October CMS, patched in v3.7.13 and v4.0.12)

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.

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

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) for reporting the issue.

For more information

If you have any questions or comments about this advisory:

• Email us at hello@wintercms.com

Impact

Backend\Widgets\Lists::evalImageTypeValue() interpolated the resolved image URL into a single-quoted src attribute without escaping it. Where a list column of type image rendered an attacker-influenced value, that value could break out of the attribute and inject arbitrary attributes — including event handlers — into the backend list, executing in the session of whichever backend user viewed it.

Winter core ships no image list column, so a default installation is unaffected. Exploitation requires a plugin that renders attacker-influenced values through one.

The supported image sources are plugins, themes, the Media Library, the uploads directory, and Attach\File models; an arbitrary external URL is not among them. ImageResizer::filterGetUrl() returns the value it was given when it cannot resolve an image, however, so an unsupported value reached the attribute verbatim rather than being rejected.

As with previous issues of this kind the severity is limited: an attacker must already be able to store the value, and a backend user must then open the affected list. Note that validating a stored URL was not necessarily sufficient — a payload can survive filter_var($url, FILTER_VALIDATE_URL), since / is valid both in a URL path and after a quoted HTML attribute value.

Patches

evalImageTypeValue() now escapes the image URL, along with the width and height taken from the column configuration, before interpolating them into the tag.

This security issue has been fixed as of v1.2.14 (commit 0941c9816181095fe35d58e78e6d0c4a49238967).

Workarounds

Apply the commit above to modules/backend/widgets/Lists.php manually if you are unable to upgrade to v1.2.14.

References

• https://github.com/wintercms/winter/security/advisories/GHSA-43w4-4j3c-jx29
• https://github.com/wintercms/winter/commit/0941c9816181095fe35d58e78e6d0c4a49238967

Credit to Seungyeon Park (@sy460129) for reporting the issue.

For more information

If you have any questions or comments about this advisory:

• Email us at hello@wintercms.com

Impact

Affected versions of Winter CMS allow authenticated backend users with the following permissions to disclose arbitrary files readable by the PHP process by injecting @import (inline) "<path>" directives into LESS source that the backend compiles. Four entry points share the same root cause:

• Brand Settings BrandSetting.custom_css field (backend.manage_branding) — compiled inline into every backend page's <style> block.
• Editor Settings EditorSetting.html_custom_styles field (backend.manage_editor) — compiled inline into every backend page's <style> block.
• Mail Brand Settings MailBrandSetting colour-picker fields (system.manage_mail_templates) — values are concatenated into LESS source via Less_Parser::ModifyVars() with no escaping, so any value the form validator does not reject can carry an @import directive.
• Theme .less/.sass/.scss assets (cms.manage_assets) — compiled through System\Classes\CombineAssets when served, with the same Less_Parser configuration. Both absolute paths and .. traversal escape from the asset's own tree were exploitable.

The leaked content includes any file the web process can read, most importantly the application .env file (disclosing APP_KEY and database credentials).

To actively exploit this issue, an attacker would need an authenticated backend account with one of the permissions listed above. By default these are assigned to the built-in Developer role.

Patches

The root cause is in the wikimedia/less.php integration in Winter Storm: Less_Parser was instantiated without a safe import resolver, and its Less_FileManager::getFilePath() falls back to the raw attacker-supplied path when no candidate root matches. Storm now ships a LessImportResolver that uses the callable form of Less_Parser::SetImportDirs() to refuse any @import whose resolved path lies outside the calling context's allowed roots, defeating both absolute paths and .. traversal at the parser level.

The four sinks have been updated to use the resolver. The three settings models pass no allowed roots (deny-all) because the bundled stylesheets ship no @import directives and the user fields have no legitimate use for them. System\Classes\CombineAssets configures the theme-asset compiler with themes_path(), plugins_path(), and base_path('modules') as allowed roots, preserving real cross-tree imports observed in shipped themes and plugins.

This security issue has been fixed in v1.2.13 (Winter core) and v1.2.13 (Winter Storm).

Workarounds

If you cannot upgrade, apply https://github.com/wintercms/storm/commit/af770331c683e628533a6ec2991285d6e10a4d6c and https://github.com/wintercms/winter/commit/130f0ea43e9228bf0d129b481da1cdfbcc4b4456 manually. As an interim mitigation, remove cms.manage_assets from any non-trusted role and clear any non-empty value from the Brand Settings custom_css and Editor Settings html_custom_styles fields.

References

See https://github.com/octobercms/october/security/advisories/GHSA-3888-q23f-x7qh for the related (but distinct in scope) October CMS advisory addressing the theme-asset compiler path. The Brand/Editor/Mail Brand Settings sinks reported in this advisory are not covered by the October patch.

Credit to Nguyen Van Hiep (@hypnguyen1209) from Lo Security for reporting the issue.

For more information

If you have any questions or comments about this advisory:

• Email us at hello@wintercms.com

Impact

The backend FileUpload form widget trusted an attacker-controlled file_id POST parameter when resolving the attachment it operates on. The lookup (FileUpload::getFileRecord()) resolved the posted id against the global system_files table without verifying that the file belonged to the widget's own relation, parent record, or deferred-binding session.

Any authenticated backend user who can reach a form containing a fileupload field — including the built-in My Account avatar field, which requires no specific backend permission — could therefore target a System\Models\File record belonging to another user or record and:

• modify its title and description via onSaveAttachmentConfig, and
• change its sort_order via onSortAttachments (which passed posted ids straight to setSortableOrder(), an unscoped UPDATE ... WHERE id = ?).

The same unscoped lookup is reached by onLoadAttachmentConfig, onSaveAttachmentConfig, and onRemoveAttachment. Because all attachments share the single System\Models\File model and system_files table, an attacker was not limited to other users' avatars — any attachment on any model could be referenced by id. Attachment ids are sequential integers and are easily enumerated.

The confirmed impact is unauthorized integrity modification of arbitrary attachment metadata and ordering.

CSRF tokens are still verified on all POST requests, so an attacker must be authenticated to the backend with a valid session. To exploit this issue an attacker needs a backend account with any level of access.

Patches

The FileUpload widget now scopes every file_id lookup to the widget's own relation, including any files bound through the current deferred-binding session, so a posted id can no longer reference an unrelated System\Models\File record:

• getFileRecord() resolves the id through getRelationObject()->withDeferred($this->sessionKey)->find(...) rather than the global file model. This covers onLoadAttachmentConfig, onSaveAttachmentConfig, and onRemoveAttachment.
• onSortAttachments() intersects the posted ids with the ids that actually belong to the relation before calling setSortableOrder().

This security issue has been fixed as of v1.2.13 (commit 9cb0ae5f9d837db141ab111c6a7de8eed9603d25).

Workarounds

There is no supported workaround other than upgrading. If you cannot upgrade immediately, you may apply the fix manually in modules/backend/formwidgets/FileUpload.php:

1. In getFileRecord(), replace $this->getRelationModel()->find(post('file_id')) with $this->getRelationObject()->withDeferred($this->sessionKey)->find(post('file_id')).
2. In onSortAttachments(), filter the posted sortOrder ids to those returned by $this->getRelationObject()->withDeferred($this->sessionKey)->pluck($keyName) before calling setSortableOrder().

Impact

Affected versions of Winter CMS did not validate the handler name submitted through the form postback mechanism (_handler POST field) in the same way as AJAX requests (X_WINTER_REQUEST_HANDLER header). The AJAX path validates that handler names match the on[A-Z][\w+]* pattern, but the postback path passed the handler name directly to the handler dispatcher with no validation.

This allowed an authenticated backend user to call any method on a controller — including action-prefixed, protected, and private methods — by submitting a crafted POST request with a _handler field, as long as the controller either:

• Contains a publicly available action via the $publicActions property, or
• Degrades or removes the $requiredPermissions check in its constructor based on a condition

The backend's own Users controller was affected by the second scenario: it set $requiredPermissions to null for the myaccount action, allowing any authenticated backend user to access the controller without the backend.manage_users permission. Combined with the postback bypass, this allowed calling controller methods such as update_onDelete, update_onRestore, update_onUnsuspendUser, and update_onManualPasswordReset with attacker-controlled parameters.

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 security issue, an attacker would need access to the Backend with a user account with any level of access.

The Winter CMS maintainers strongly recommend that all Winter CMS sites that have any reliance on the roles & permissions system to update immediately. Security fixes have been backported to all major versions of Winter (1.0, 1.1, and 1.2).

Patches

The postback handler path now validates handler names using the same rules as the AJAX path. The My Account functionality has been moved to a dedicated controller that does not expose user management methods. Defence in depth has been applied at the model level to prevent unauthorized user record modifications regardless of the entry point.

This security issue has been fixed as of v1.2.13.

Workarounds

If users cannot upgrade, they may apply the following changes to their Winter CMS installation manually to resolve this issue:

1. In modules/backend/classes/Controller.php, validate the _handler POST field against the on[A-Z][\w+]* pattern before passing it to runAjaxHandler().
2. In modules/backend/controllers/Users.php, remove the conditional that sets $requiredPermissions to null for the myaccount action.

Impact

The Backend Filter widget (Backend\Widgets\Filter) is vulnerable to SQL injection through the numberrange scope type when the scope is configured with a conditions key. An authenticated backend user with access to a list view containing a vulnerable filter scope can inject arbitrary SQL via the filter's AJAX handler, potentially gaining read access to the full database contents.

To exploit this, an attacker must have a valid backend account with access to a list view where a third-party plugin has registered a numberrange filter scope using the conditions configuration key. No built-in Winter CMS backend views use this scope type and configuration combination, so a vanilla installation without plugins is not exploitable.

Patches

This issue has been fixed in Winter CMS v1.2.13.

Workarounds

If users cannot upgrade, they may apply commit https://github.com/wintercms/winter/commit/50713de95adf5298536d93f4d999652525d36d43 to your Winter CMS installation manually to resolve this issue.

Impact

Authenticated Backend Users with the backend.manage_editor ("Manage editor settings") permission can provide custom styles through Settings → Editor Settings → Markup Styles that are compiled through the LESS CSS parser and rendered on every backend page. Previously, the compiled output was not sanitized, which could have allowed a stored XSS attack.

Although this is a valid security issue, it's important to note that its severity is relatively low. To exploit the vulnerability, an attacker would already need to have trusted access to the Winter CMS backend with a specific administrative permission. The Winter CMS maintainers recommend that the backend.manage_editor permission only be granted to trusted administrators and developers.

A related issue exists in the custom CSS field at Settings → Customize Backend → Styles (backend.manage_branding permission), which uses the same rendering mechanism and is addressed separately.

All users are advised to update to the latest version to ensure their systems remain secure.

Patches

This issue has been patched in v1.2.13. The renderCss() method now applies strip_tags() to compiled CSS output before returning it.

Workarounds

Apply https://github.com/wintercms/winter/commit/d28f0b9474af79cfaa80eeb9d691f7a7c4469720 manually if unable to upgrade to v1.2.13.

Resources

• CVE-2025-61674 (identical vulnerability in October CMS, patched in v3.7.13 and v4.0.12)

Impact

Users with the backend.manage_branding ("Customize the back-end") permission can provide custom CSS through Settings → Customize Backend → Styles that is compiled through the LESS CSS parser and rendered on every backend page. Previously, the compiled output was not sanitized, which could have allowed a stored XSS attack.

Although this is a valid security issue, it's important to note that its severity is relatively low. To exploit the vulnerability, an attacker would already need to have trusted access to the Winter CMS backend with a specific administrative permission. The Winter CMS maintainers recommend that the backend.manage_branding permission only be granted to trusted administrators and developers.

A related issue exists in the custom styles field at Settings → Editor Settings → Markup Styles (backend.manage_editor permission), which uses the same rendering mechanism and is addressed separately.

All users are advised to update to the latest version to ensure their systems remain secure.

Patches

This issue has been patched in v1.2.13.

Workarounds

Apply https://github.com/wintercms/winter/commit/d28f0b9474af79cfaa80eeb9d691f7a7c4469720 manually if unable to upgrade to v1.2.13.

Resources

• CVE-2025-61676 (identical vulnerability in October CMS, patched in v3.7.13 and v4.0.12)

Impact

Affected versions of Winter CMS allowed authenticated backend users to escalate their accounts level of access to the system by modifying the roles / permissions assigned to their account through specially crafted requests to the backend while logged in.

To actively exploit this security issue, an attacker would need access to the Backend with a user account with any level of access.

The Winter CMS maintainers strongly recommend that all Winter CMS sites that have any reliance on the roles & permissions system to update immediately. Security fixes have been backported to all major versions of Winter (1.0, 1.1, and 1.2).

Patches

Multiple fixes and defence in depth has been applied to prevent current and future privilege escalation attacks at the lowest level possible.

This security issue has been fixed as of https://wintercms.com/releases/v1.0.477, https://wintercms.com/releases/v1.1.12, https://wintercms.com/releases/v1.2.12.

Workarounds

If you cannot upgrade, you may apply the changes from the releases to your Winter CMS installation manually to resolve this issue.

Impact

Affected versions of Winter CMS render the search query parameter without HTML encoding inside a <script type="text/template"> block in the backend Table widget partial (modules/backend/widgets/table/partials/_table.php):

value="<?= get('search') ?>"

<script> is an HTML raw-text context, so the surrounding value="…" attribute quoting is not a parser boundary. A literal </script> in the query string terminates the template element early, and everything after it is parsed as ordinary markup in the backend document.

Any backend page rendering a Table or DataTable widget is a sink. The value is read from the global request through the get() helper, which — unlike post() — is not restricted by HTTP method, so a plain top-level GET navigation is sufficient. The template is also emitted unconditionally by the partial, so widgets using the default searching: false configuration are equally affected.

In Winter core the reachable route is the Editor Settings form (/backend/system/settings/update/winter/backend/editor), which renders six datatable fields and is gated by backend.manage_editor — assigned by default to the built-in Developer role. Third-party plugins using the datatable form widget, or the Table widget directly, expose the same sink on their own pages.

An attacker who induces a signed-in backend user to follow a crafted link executes script in that user's authenticated backend origin. The injected script can read the CSRF token published in the backend layout's <meta name="csrf-token"> element and issue credentialed requests as the victim, bounded only by that user's permissions. Because the core sink requires backend.manage_editor, the practical victim is a Developer-role user or superuser — who can edit CMS templates, so script running in that session can chain to server-side code execution.

This is not a permission bypass: the victim must already be authorised for the page, and the attacker gains no permission the victim does not hold.

To actively exploit this issue, an attacker needs no account of their own, but does need an authenticated backend user with access to a page rendering a Table or DataTable widget to follow an attacker-supplied link.

Patches

The search value is now HTML-encoded on output, matching every other value rendered by the same partial and the equivalent handling in the backend Search widget (modules/backend/widgets/search/partials/_search.php):

value="<?= e(get('search')); ?>"

This removes the raw-text terminator: the browser can no longer encounter an attacker-supplied literal </script> while tokenising the document. The template is subsequently parsed once by jQuery when the toolbar is built, so an encoded payload resolves to an inert attribute string rather than markup.

Regression coverage was added in modules/backend/tests/widgets/TableSearchEscapingTest.php, covering plain, mixed-case (</ScRiPt>) and whitespace-bearing (</script >) terminators, both searching states, and preservation of ordinary and Unicode search text.

This security issue has been fixed in v1.2.14.

Workarounds

If you cannot upgrade, apply https://github.com/wintercms/winter/commit/1b6397654124fb44a6abf6f3782b6a1d746cef14 manually — in modules/backend/widgets/table/partials/_table.php, change:

value="<?= get('search') ?>"

to:

value="<?= e(get('search')); ?>"

A restrictive Content Security Policy served at the web server or reverse proxy can reduce practical exploitability, but it is not a substitute for the fix: Winter's backend ships inline scripts, so a policy permissive enough to run the backend may still permit an injected execution primitive.

References

Credit to Awwader (@NRAwwad) for reporting the issue.

For more information

If you have any questions or comments about this advisory:

• Email us at hello@wintercms.com

Impact

Affected versions of Winter CMS allow a backend AJAX handler to be invoked by a plain top-level GET navigation with no CSRF token. Backend\Classes\Controller::actionExists() accepted any public method on a controller as a page action, so handler-shaped names were never reserved from URL dispatch: an authenticated and authorized request to /backend/system/eventlogs/index_onEmptyLog reached the handler of the same name and truncated the system event log. Backend paths are routed through Route::any, and CSRF validation is skipped for HEAD, GET and OPTIONS requests.

The default SameSite=Lax session cookie is sent on top-level cross-site navigation, so a link on an attacker-controlled page is sufficient — no form, no script and no token. Handler arguments are taken from URL path segments, so the attacker also chooses the target record. Affected handlers across the backend, cms and system modules cover log truncation, resetting settings to their defaults, altering backend user state, and deleting CMS templates. None of them disclose data to the attacker or write attacker-controlled content, so the impact is destructive and state-changing rather than confidential.

To actively exploit this issue, an attacker would need no account of their own, but would need an authenticated backend user holding the relevant permission to follow an attacker-supplied link. The permissions guarding the affected handlers, system.access_logs included, are by default assigned only to the built-in Developer role.

Patches

Page-action dispatch is now restricted to all-lowercase method names, which reserves handler-shaped names (onFoo, index_onFoo) from being reached by URL. AJAX dispatch is unchanged: handlers continue to work over POST with the X-WINTER-REQUEST-HANDLER header exactly as before, and need no changes.

IMPORTANT: This fix includes a breaking change to backend action routing. A public controller method used as a page action must now be named in lowercase — coming_soon() rather than comingSoon() — and dashed URLs are normalised to snake_case, so /coming-soon now resolves to coming_soon() instead of comingSoon(). Plugins with a camelCase page action should rename the method and its view file to match; the published URL does not need to change. Core is unaffected, and a survey of the plugin ecosystem found the change affects only a small number of plugins.

This security issue has been fixed in v1.2.14.

Workarounds

If you cannot upgrade, apply https://github.com/wintercms/winter/commit/353b23804dee2acf49fca996c72637040446824f manually.

As an interim mitigation, set 'same_site' => 'strict' in config/session.php. A strict session cookie is not sent on cross-site top-level navigation, which prevents the victim's session accompanying an attacker's link. Review this against any single sign-on or inbound-link flows into your backend first, as it also affects legitimate cross-site entry.

References

Credit to Awwader (@NRAwwad) for reporting the issue.

For more information

If you have any questions or comments about this advisory:

• Email us at hello@wintercms.com

Impact

Users with the backend.manage_branding ("Customize the back-end") or backend.manage_editor ("Manage global code editor preferences") permission can provide custom CSS through Settings → Customize Backend → Styles or Settings → Editor Settings → Markup Styles that is compiled through the LESS CSS parser and rendered on every backend page.

v1.2.13 addressed CVE-2026-32257 and CVE-2026-32258 by applying strip_tags() to the compiled output of BrandSetting::renderCss() and EditorSetting::renderCss(). That fix was incomplete. Both methods cache the raw compiler output with Cache::forever() and applied strip_tags() only to the value returned on a cache miss, so every subsequent cache hit returned the unsanitized value directly into the backend <style> element. The first page render after saving therefore appears sanitized while priming an unsafe cache entry, and the stored XSS remains exploitable from the second render onwards.

Because the custom styles partial is included by both the standard backend layout head and the backend authentication layout, an injected payload also renders on the unauthenticated backend sign-in, password restore, and password reset pages.

Although this is a valid security issue, it's important to note that its severity is relatively low. To exploit the vulnerability, an attacker would already need to have trusted access to the Winter CMS backend with a specific administrative permission. The Winter CMS maintainers recommend that the backend.manage_branding and backend.manage_editor permissions only be granted to trusted administrators and developers.

All users are advised to update to the latest version to ensure their systems remain secure.

Patches

This issue has been patched in v1.2.14. The renderCss() methods now apply strip_tags() to the cached value when it is read back, which also neutralizes any cache entry that was poisoned before upgrading.

The backend.manage_editor and backend.manage_default_dashboard permissions have additionally been given warning comments in the permission editor, matching the existing warning on backend.manage_branding.

Workarounds

Apply https://github.com/wintercms/winter/commit/c95d780ab54f3a3f74a94ae1667bf12b3c549d5d manually if unable to upgrade to v1.2.14.

Clearing the application cache removes an already-poisoned entry, but it will be recreated on the next backend page render unless the patch is applied.

References

• CVE-2026-32257 / GHSA-v7cf-8gh9-gxmj (Stored XSS through Brand Settings custom styles, incompletely patched in v1.2.13)
• CVE-2026-32258 / GHSA-vgp4-2fc4-qff2 (Stored XSS through Editor Settings custom styles, incompletely patched in v1.2.13)
• CVE-2025-61674 and CVE-2025-61676 (identical vulnerability in October CMS, patched in v3.7.13 and v4.0.12)

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.

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

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) for reporting the issue.

For more information

If you have any questions or comments about this advisory:

• Email us at hello@wintercms.com

Impact

Backend\Widgets\Lists::evalImageTypeValue() interpolated the resolved image URL into a single-quoted src attribute without escaping it. Where a list column of type image rendered an attacker-influenced value, that value could break out of the attribute and inject arbitrary attributes — including event handlers — into the backend list, executing in the session of whichever backend user viewed it.

Winter core ships no image list column, so a default installation is unaffected. Exploitation requires a plugin that renders attacker-influenced values through one.

The supported image sources are plugins, themes, the Media Library, the uploads directory, and Attach\File models; an arbitrary external URL is not among them. ImageResizer::filterGetUrl() returns the value it was given when it cannot resolve an image, however, so an unsupported value reached the attribute verbatim rather than being rejected.

As with previous issues of this kind the severity is limited: an attacker must already be able to store the value, and a backend user must then open the affected list. Note that validating a stored URL was not necessarily sufficient — a payload can survive filter_var($url, FILTER_VALIDATE_URL), since / is valid both in a URL path and after a quoted HTML attribute value.

Patches

evalImageTypeValue() now escapes the image URL, along with the width and height taken from the column configuration, before interpolating them into the tag.

This security issue has been fixed as of v1.2.14 (commit 0941c9816181095fe35d58e78e6d0c4a49238967).

Workarounds

Apply the commit above to modules/backend/widgets/Lists.php manually if you are unable to upgrade to v1.2.14.

References

• https://github.com/wintercms/winter/security/advisories/GHSA-43w4-4j3c-jx29
• https://github.com/wintercms/winter/commit/0941c9816181095fe35d58e78e6d0c4a49238967

Credit to Seungyeon Park (@sy460129) for reporting the issue.

For more information

If you have any questions or comments about this advisory:

• Email us at hello@wintercms.com

Impact

Affected versions of Winter CMS allow authenticated backend users with the following permissions to disclose arbitrary files readable by the PHP process by injecting @import (inline) "<path>" directives into LESS source that the backend compiles. Four entry points share the same root cause:

• Brand Settings BrandSetting.custom_css field (backend.manage_branding) — compiled inline into every backend page's <style> block.
• Editor Settings EditorSetting.html_custom_styles field (backend.manage_editor) — compiled inline into every backend page's <style> block.
• Mail Brand Settings MailBrandSetting colour-picker fields (system.manage_mail_templates) — values are concatenated into LESS source via Less_Parser::ModifyVars() with no escaping, so any value the form validator does not reject can carry an @import directive.
• Theme .less/.sass/.scss assets (cms.manage_assets) — compiled through System\Classes\CombineAssets when served, with the same Less_Parser configuration. Both absolute paths and .. traversal escape from the asset's own tree were exploitable.

The leaked content includes any file the web process can read, most importantly the application .env file (disclosing APP_KEY and database credentials).

To actively exploit this issue, an attacker would need an authenticated backend account with one of the permissions listed above. By default these are assigned to the built-in Developer role.

Patches

The root cause is in the wikimedia/less.php integration in Winter Storm: Less_Parser was instantiated without a safe import resolver, and its Less_FileManager::getFilePath() falls back to the raw attacker-supplied path when no candidate root matches. Storm now ships a LessImportResolver that uses the callable form of Less_Parser::SetImportDirs() to refuse any @import whose resolved path lies outside the calling context's allowed roots, defeating both absolute paths and .. traversal at the parser level.

The four sinks have been updated to use the resolver. The three settings models pass no allowed roots (deny-all) because the bundled stylesheets ship no @import directives and the user fields have no legitimate use for them. System\Classes\CombineAssets configures the theme-asset compiler with themes_path(), plugins_path(), and base_path('modules') as allowed roots, preserving real cross-tree imports observed in shipped themes and plugins.

This security issue has been fixed in v1.2.13 (Winter core) and v1.2.13 (Winter Storm).

Workarounds

If you cannot upgrade, apply https://github.com/wintercms/storm/commit/af770331c683e628533a6ec2991285d6e10a4d6c and https://github.com/wintercms/winter/commit/130f0ea43e9228bf0d129b481da1cdfbcc4b4456 manually. As an interim mitigation, remove cms.manage_assets from any non-trusted role and clear any non-empty value from the Brand Settings custom_css and Editor Settings html_custom_styles fields.

References

See https://github.com/octobercms/october/security/advisories/GHSA-3888-q23f-x7qh for the related (but distinct in scope) October CMS advisory addressing the theme-asset compiler path. The Brand/Editor/Mail Brand Settings sinks reported in this advisory are not covered by the October patch.

Credit to Nguyen Van Hiep (@hypnguyen1209) from Lo Security for reporting the issue.

For more information

If you have any questions or comments about this advisory:

• Email us at hello@wintercms.com

Impact

The backend FileUpload form widget trusted an attacker-controlled file_id POST parameter when resolving the attachment it operates on. The lookup (FileUpload::getFileRecord()) resolved the posted id against the global system_files table without verifying that the file belonged to the widget's own relation, parent record, or deferred-binding session.

Any authenticated backend user who can reach a form containing a fileupload field — including the built-in My Account avatar field, which requires no specific backend permission — could therefore target a System\Models\File record belonging to another user or record and:

• modify its title and description via onSaveAttachmentConfig, and
• change its sort_order via onSortAttachments (which passed posted ids straight to setSortableOrder(), an unscoped UPDATE ... WHERE id = ?).

The same unscoped lookup is reached by onLoadAttachmentConfig, onSaveAttachmentConfig, and onRemoveAttachment. Because all attachments share the single System\Models\File model and system_files table, an attacker was not limited to other users' avatars — any attachment on any model could be referenced by id. Attachment ids are sequential integers and are easily enumerated.

The confirmed impact is unauthorized integrity modification of arbitrary attachment metadata and ordering.

CSRF tokens are still verified on all POST requests, so an attacker must be authenticated to the backend with a valid session. To exploit this issue an attacker needs a backend account with any level of access.

Patches

The FileUpload widget now scopes every file_id lookup to the widget's own relation, including any files bound through the current deferred-binding session, so a posted id can no longer reference an unrelated System\Models\File record:

• getFileRecord() resolves the id through getRelationObject()->withDeferred($this->sessionKey)->find(...) rather than the global file model. This covers onLoadAttachmentConfig, onSaveAttachmentConfig, and onRemoveAttachment.
• onSortAttachments() intersects the posted ids with the ids that actually belong to the relation before calling setSortableOrder().

This security issue has been fixed as of v1.2.13 (commit 9cb0ae5f9d837db141ab111c6a7de8eed9603d25).

Workarounds

There is no supported workaround other than upgrading. If you cannot upgrade immediately, you may apply the fix manually in modules/backend/formwidgets/FileUpload.php:

1. In getFileRecord(), replace $this->getRelationModel()->find(post('file_id')) with $this->getRelationObject()->withDeferred($this->sessionKey)->find(post('file_id')).
2. In onSortAttachments(), filter the posted sortOrder ids to those returned by $this->getRelationObject()->withDeferred($this->sessionKey)->pluck($keyName) before calling setSortableOrder().

Impact

Affected versions of Winter CMS did not validate the handler name submitted through the form postback mechanism (_handler POST field) in the same way as AJAX requests (X_WINTER_REQUEST_HANDLER header). The AJAX path validates that handler names match the on[A-Z][\w+]* pattern, but the postback path passed the handler name directly to the handler dispatcher with no validation.

This allowed an authenticated backend user to call any method on a controller — including action-prefixed, protected, and private methods — by submitting a crafted POST request with a _handler field, as long as the controller either:

• Contains a publicly available action via the $publicActions property, or
• Degrades or removes the $requiredPermissions check in its constructor based on a condition

The backend's own Users controller was affected by the second scenario: it set $requiredPermissions to null for the myaccount action, allowing any authenticated backend user to access the controller without the backend.manage_users permission. Combined with the postback bypass, this allowed calling controller methods such as update_onDelete, update_onRestore, update_onUnsuspendUser, and update_onManualPasswordReset with attacker-controlled parameters.

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 security issue, an attacker would need access to the Backend with a user account with any level of access.

The Winter CMS maintainers strongly recommend that all Winter CMS sites that have any reliance on the roles & permissions system to update immediately. Security fixes have been backported to all major versions of Winter (1.0, 1.1, and 1.2).

Patches

The postback handler path now validates handler names using the same rules as the AJAX path. The My Account functionality has been moved to a dedicated controller that does not expose user management methods. Defence in depth has been applied at the model level to prevent unauthorized user record modifications regardless of the entry point.

This security issue has been fixed as of v1.2.13.

Workarounds

If users cannot upgrade, they may apply the following changes to their Winter CMS installation manually to resolve this issue:

1. In modules/backend/classes/Controller.php, validate the _handler POST field against the on[A-Z][\w+]* pattern before passing it to runAjaxHandler().
2. In modules/backend/controllers/Users.php, remove the conditional that sets $requiredPermissions to null for the myaccount action.

Impact

The Backend Filter widget (Backend\Widgets\Filter) is vulnerable to SQL injection through the numberrange scope type when the scope is configured with a conditions key. An authenticated backend user with access to a list view containing a vulnerable filter scope can inject arbitrary SQL via the filter's AJAX handler, potentially gaining read access to the full database contents.

To exploit this, an attacker must have a valid backend account with access to a list view where a third-party plugin has registered a numberrange filter scope using the conditions configuration key. No built-in Winter CMS backend views use this scope type and configuration combination, so a vanilla installation without plugins is not exploitable.

Patches

This issue has been fixed in Winter CMS v1.2.13.

Workarounds

If users cannot upgrade, they may apply commit https://github.com/wintercms/winter/commit/50713de95adf5298536d93f4d999652525d36d43 to your Winter CMS installation manually to resolve this issue.

Impact

Users with the backend.manage_branding ("Customize the back-end") permission can provide custom CSS through Settings → Customize Backend → Styles that is compiled through the LESS CSS parser and rendered on every backend page. Previously, the compiled output was not sanitized, which could have allowed a stored XSS attack.

Although this is a valid security issue, it's important to note that its severity is relatively low. To exploit the vulnerability, an attacker would already need to have trusted access to the Winter CMS backend with a specific administrative permission. The Winter CMS maintainers recommend that the backend.manage_branding permission only be granted to trusted administrators and developers.

A related issue exists in the custom styles field at Settings → Editor Settings → Markup Styles (backend.manage_editor permission), which uses the same rendering mechanism and is addressed separately.

All users are advised to update to the latest version to ensure their systems remain secure.

Patches

This issue has been patched in v1.2.13.

Workarounds

Apply https://github.com/wintercms/winter/commit/d28f0b9474af79cfaa80eeb9d691f7a7c4469720 manually if unable to upgrade to v1.2.13.

Resources

• CVE-2025-61676 (identical vulnerability in October CMS, patched in v3.7.13 and v4.0.12)

Impact

Affected versions of Winter CMS allowed authenticated backend users to escalate their accounts level of access to the system by modifying the roles / permissions assigned to their account through specially crafted requests to the backend while logged in.

To actively exploit this security issue, an attacker would need access to the Backend with a user account with any level of access.

The Winter CMS maintainers strongly recommend that all Winter CMS sites that have any reliance on the roles & permissions system to update immediately. Security fixes have been backported to all major versions of Winter (1.0, 1.1, and 1.2).

Patches

Multiple fixes and defence in depth has been applied to prevent current and future privilege escalation attacks at the lowest level possible.

This security issue has been fixed as of https://wintercms.com/releases/v1.0.477, https://wintercms.com/releases/v1.1.12, https://wintercms.com/releases/v1.2.12.

Workarounds

If you cannot upgrade, you may apply the changes from the releases to your Winter CMS installation manually to resolve this issue.

Impact

Affected versions of Winter CMS render the search query parameter without HTML encoding inside a <script type="text/template"> block in the backend Table widget partial (modules/backend/widgets/table/partials/_table.php):

value="<?= get('search') ?>"

<script> is an HTML raw-text context, so the surrounding value="…" attribute quoting is not a parser boundary. A literal </script> in the query string terminates the template element early, and everything after it is parsed as ordinary markup in the backend document.

Any backend page rendering a Table or DataTable widget is a sink. The value is read from the global request through the get() helper, which — unlike post() — is not restricted by HTTP method, so a plain top-level GET navigation is sufficient. The template is also emitted unconditionally by the partial, so widgets using the default searching: false configuration are equally affected.

In Winter core the reachable route is the Editor Settings form (/backend/system/settings/update/winter/backend/editor), which renders six datatable fields and is gated by backend.manage_editor — assigned by default to the built-in Developer role. Third-party plugins using the datatable form widget, or the Table widget directly, expose the same sink on their own pages.

An attacker who induces a signed-in backend user to follow a crafted link executes script in that user's authenticated backend origin. The injected script can read the CSRF token published in the backend layout's <meta name="csrf-token"> element and issue credentialed requests as the victim, bounded only by that user's permissions. Because the core sink requires backend.manage_editor, the practical victim is a Developer-role user or superuser — who can edit CMS templates, so script running in that session can chain to server-side code execution.

This is not a permission bypass: the victim must already be authorised for the page, and the attacker gains no permission the victim does not hold.

To actively exploit this issue, an attacker needs no account of their own, but does need an authenticated backend user with access to a page rendering a Table or DataTable widget to follow an attacker-supplied link.

Patches

The search value is now HTML-encoded on output, matching every other value rendered by the same partial and the equivalent handling in the backend Search widget (modules/backend/widgets/search/partials/_search.php):

value="<?= e(get('search')); ?>"

This removes the raw-text terminator: the browser can no longer encounter an attacker-supplied literal </script> while tokenising the document. The template is subsequently parsed once by jQuery when the toolbar is built, so an encoded payload resolves to an inert attribute string rather than markup.

Regression coverage was added in modules/backend/tests/widgets/TableSearchEscapingTest.php, covering plain, mixed-case (</ScRiPt>) and whitespace-bearing (</script >) terminators, both searching states, and preservation of ordinary and Unicode search text.

This security issue has been fixed in v1.2.14.

Workarounds

If you cannot upgrade, apply https://github.com/wintercms/winter/commit/1b6397654124fb44a6abf6f3782b6a1d746cef14 manually — in modules/backend/widgets/table/partials/_table.php, change:

value="<?= get('search') ?>"

to:

value="<?= e(get('search')); ?>"

A restrictive Content Security Policy served at the web server or reverse proxy can reduce practical exploitability, but it is not a substitute for the fix: Winter's backend ships inline scripts, so a policy permissive enough to run the backend may still permit an injected execution primitive.

References

Credit to Awwader (@NRAwwad) for reporting the issue.

For more information

If you have any questions or comments about this advisory:

• Email us at hello@wintercms.com

Impact

Affected versions of Winter CMS allow a backend AJAX handler to be invoked by a plain top-level GET navigation with no CSRF token. Backend\Classes\Controller::actionExists() accepted any public method on a controller as a page action, so handler-shaped names were never reserved from URL dispatch: an authenticated and authorized request to /backend/system/eventlogs/index_onEmptyLog reached the handler of the same name and truncated the system event log. Backend paths are routed through Route::any, and CSRF validation is skipped for HEAD, GET and OPTIONS requests.

The default SameSite=Lax session cookie is sent on top-level cross-site navigation, so a link on an attacker-controlled page is sufficient — no form, no script and no token. Handler arguments are taken from URL path segments, so the attacker also chooses the target record. Affected handlers across the backend, cms and system modules cover log truncation, resetting settings to their defaults, altering backend user state, and deleting CMS templates. None of them disclose data to the attacker or write attacker-controlled content, so the impact is destructive and state-changing rather than confidential.

To actively exploit this issue, an attacker would need no account of their own, but would need an authenticated backend user holding the relevant permission to follow an attacker-supplied link. The permissions guarding the affected handlers, system.access_logs included, are by default assigned only to the built-in Developer role.

Patches

Page-action dispatch is now restricted to all-lowercase method names, which reserves handler-shaped names (onFoo, index_onFoo) from being reached by URL. AJAX dispatch is unchanged: handlers continue to work over POST with the X-WINTER-REQUEST-HANDLER header exactly as before, and need no changes.

IMPORTANT: This fix includes a breaking change to backend action routing. A public controller method used as a page action must now be named in lowercase — coming_soon() rather than comingSoon() — and dashed URLs are normalised to snake_case, so /coming-soon now resolves to coming_soon() instead of comingSoon(). Plugins with a camelCase page action should rename the method and its view file to match; the published URL does not need to change. Core is unaffected, and a survey of the plugin ecosystem found the change affects only a small number of plugins.

This security issue has been fixed in v1.2.14.

Workarounds

If you cannot upgrade, apply https://github.com/wintercms/winter/commit/353b23804dee2acf49fca996c72637040446824f manually.

As an interim mitigation, set 'same_site' => 'strict' in config/session.php. A strict session cookie is not sent on cross-site top-level navigation, which prevents the victim's session accompanying an attacker's link. Review this against any single sign-on or inbound-link flows into your backend first, as it also affects legitimate cross-site entry.

References

Credit to Awwader (@NRAwwad) for reporting the issue.

For more information

If you have any questions or comments about this advisory:

• Email us at hello@wintercms.com

Impact

Users with the backend.manage_branding ("Customize the back-end") or backend.manage_editor ("Manage global code editor preferences") permission can provide custom CSS through Settings → Customize Backend → Styles or Settings → Editor Settings → Markup Styles that is compiled through the LESS CSS parser and rendered on every backend page.

v1.2.13 addressed CVE-2026-32257 and CVE-2026-32258 by applying strip_tags() to the compiled output of BrandSetting::renderCss() and EditorSetting::renderCss(). That fix was incomplete. Both methods cache the raw compiler output with Cache::forever() and applied strip_tags() only to the value returned on a cache miss, so every subsequent cache hit returned the unsanitized value directly into the backend <style> element. The first page render after saving therefore appears sanitized while priming an unsafe cache entry, and the stored XSS remains exploitable from the second render onwards.

Because the custom styles partial is included by both the standard backend layout head and the backend authentication layout, an injected payload also renders on the unauthenticated backend sign-in, password restore, and password reset pages.

Although this is a valid security issue, it's important to note that its severity is relatively low. To exploit the vulnerability, an attacker would already need to have trusted access to the Winter CMS backend with a specific administrative permission. The Winter CMS maintainers recommend that the backend.manage_branding and backend.manage_editor permissions only be granted to trusted administrators and developers.

All users are advised to update to the latest version to ensure their systems remain secure.

Patches

This issue has been patched in v1.2.14. The renderCss() methods now apply strip_tags() to the cached value when it is read back, which also neutralizes any cache entry that was poisoned before upgrading.

The backend.manage_editor and backend.manage_default_dashboard permissions have additionally been given warning comments in the permission editor, matching the existing warning on backend.manage_branding.

Workarounds

Apply https://github.com/wintercms/winter/commit/c95d780ab54f3a3f74a94ae1667bf12b3c549d5d manually if unable to upgrade to v1.2.14.

Clearing the application cache removes an already-poisoned entry, but it will be recreated on the next backend page render unless the patch is applied.

References

• CVE-2026-32257 / GHSA-v7cf-8gh9-gxmj (Stored XSS through Brand Settings custom styles, incompletely patched in v1.2.13)
• CVE-2026-32258 / GHSA-vgp4-2fc4-qff2 (Stored XSS through Editor Settings custom styles, incompletely patched in v1.2.13)
• CVE-2025-61674 and CVE-2025-61676 (identical vulnerability in October CMS, patched in v3.7.13 and v4.0.12)

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.

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

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) for reporting the issue.

For more information

If you have any questions or comments about this advisory:

• Email us at hello@wintercms.com

Impact

Backend\Widgets\Lists::evalImageTypeValue() interpolated the resolved image URL into a single-quoted src attribute without escaping it. Where a list column of type image rendered an attacker-influenced value, that value could break out of the attribute and inject arbitrary attributes — including event handlers — into the backend list, executing in the session of whichever backend user viewed it.

Winter core ships no image list column, so a default installation is unaffected. Exploitation requires a plugin that renders attacker-influenced values through one.

The supported image sources are plugins, themes, the Media Library, the uploads directory, and Attach\File models; an arbitrary external URL is not among them. ImageResizer::filterGetUrl() returns the value it was given when it cannot resolve an image, however, so an unsupported value reached the attribute verbatim rather than being rejected.

As with previous issues of this kind the severity is limited: an attacker must already be able to store the value, and a backend user must then open the affected list. Note that validating a stored URL was not necessarily sufficient — a payload can survive filter_var($url, FILTER_VALIDATE_URL), since / is valid both in a URL path and after a quoted HTML attribute value.

Patches

evalImageTypeValue() now escapes the image URL, along with the width and height taken from the column configuration, before interpolating them into the tag.

This security issue has been fixed as of v1.2.14 (commit 0941c9816181095fe35d58e78e6d0c4a49238967).

Workarounds

Apply the commit above to modules/backend/widgets/Lists.php manually if you are unable to upgrade to v1.2.14.

References

• https://github.com/wintercms/winter/security/advisories/GHSA-43w4-4j3c-jx29
• https://github.com/wintercms/winter/commit/0941c9816181095fe35d58e78e6d0c4a49238967

Credit to Seungyeon Park (@sy460129) for reporting the issue.

For more information

If you have any questions or comments about this advisory:

• Email us at hello@wintercms.com

Impact

Affected versions of Winter CMS allow authenticated backend users with the following permissions to disclose arbitrary files readable by the PHP process by injecting @import (inline) "<path>" directives into LESS source that the backend compiles. Four entry points share the same root cause:

• Brand Settings BrandSetting.custom_css field (backend.manage_branding) — compiled inline into every backend page's <style> block.
• Editor Settings EditorSetting.html_custom_styles field (backend.manage_editor) — compiled inline into every backend page's <style> block.
• Mail Brand Settings MailBrandSetting colour-picker fields (system.manage_mail_templates) — values are concatenated into LESS source via Less_Parser::ModifyVars() with no escaping, so any value the form validator does not reject can carry an @import directive.
• Theme .less/.sass/.scss assets (cms.manage_assets) — compiled through System\Classes\CombineAssets when served, with the same Less_Parser configuration. Both absolute paths and .. traversal escape from the asset's own tree were exploitable.

The leaked content includes any file the web process can read, most importantly the application .env file (disclosing APP_KEY and database credentials).

To actively exploit this issue, an attacker would need an authenticated backend account with one of the permissions listed above. By default these are assigned to the built-in Developer role.

Patches

The root cause is in the wikimedia/less.php integration in Winter Storm: Less_Parser was instantiated without a safe import resolver, and its Less_FileManager::getFilePath() falls back to the raw attacker-supplied path when no candidate root matches. Storm now ships a LessImportResolver that uses the callable form of Less_Parser::SetImportDirs() to refuse any @import whose resolved path lies outside the calling context's allowed roots, defeating both absolute paths and .. traversal at the parser level.

The four sinks have been updated to use the resolver. The three settings models pass no allowed roots (deny-all) because the bundled stylesheets ship no @import directives and the user fields have no legitimate use for them. System\Classes\CombineAssets configures the theme-asset compiler with themes_path(), plugins_path(), and base_path('modules') as allowed roots, preserving real cross-tree imports observed in shipped themes and plugins.

This security issue has been fixed in v1.2.13 (Winter core) and v1.2.13 (Winter Storm).

Workarounds

If you cannot upgrade, apply https://github.com/wintercms/storm/commit/af770331c683e628533a6ec2991285d6e10a4d6c and https://github.com/wintercms/winter/commit/130f0ea43e9228bf0d129b481da1cdfbcc4b4456 manually. As an interim mitigation, remove cms.manage_assets from any non-trusted role and clear any non-empty value from the Brand Settings custom_css and Editor Settings html_custom_styles fields.

References

See https://github.com/octobercms/october/security/advisories/GHSA-3888-q23f-x7qh for the related (but distinct in scope) October CMS advisory addressing the theme-asset compiler path. The Brand/Editor/Mail Brand Settings sinks reported in this advisory are not covered by the October patch.

Credit to Nguyen Van Hiep (@hypnguyen1209) from Lo Security for reporting the issue.

For more information

If you have any questions or comments about this advisory:

• Email us at hello@wintercms.com

Impact

The backend FileUpload form widget trusted an attacker-controlled file_id POST parameter when resolving the attachment it operates on. The lookup (FileUpload::getFileRecord()) resolved the posted id against the global system_files table without verifying that the file belonged to the widget's own relation, parent record, or deferred-binding session.

Any authenticated backend user who can reach a form containing a fileupload field — including the built-in My Account avatar field, which requires no specific backend permission — could therefore target a System\Models\File record belonging to another user or record and:

• modify its title and description via onSaveAttachmentConfig, and
• change its sort_order via onSortAttachments (which passed posted ids straight to setSortableOrder(), an unscoped UPDATE ... WHERE id = ?).

The same unscoped lookup is reached by onLoadAttachmentConfig, onSaveAttachmentConfig, and onRemoveAttachment. Because all attachments share the single System\Models\File model and system_files table, an attacker was not limited to other users' avatars — any attachment on any model could be referenced by id. Attachment ids are sequential integers and are easily enumerated.

The confirmed impact is unauthorized integrity modification of arbitrary attachment metadata and ordering.

CSRF tokens are still verified on all POST requests, so an attacker must be authenticated to the backend with a valid session. To exploit this issue an attacker needs a backend account with any level of access.

Patches

The FileUpload widget now scopes every file_id lookup to the widget's own relation, including any files bound through the current deferred-binding session, so a posted id can no longer reference an unrelated System\Models\File record:

• getFileRecord() resolves the id through getRelationObject()->withDeferred($this->sessionKey)->find(...) rather than the global file model. This covers onLoadAttachmentConfig, onSaveAttachmentConfig, and onRemoveAttachment.
• onSortAttachments() intersects the posted ids with the ids that actually belong to the relation before calling setSortableOrder().

This security issue has been fixed as of v1.2.13 (commit 9cb0ae5f9d837db141ab111c6a7de8eed9603d25).

Workarounds

There is no supported workaround other than upgrading. If you cannot upgrade immediately, you may apply the fix manually in modules/backend/formwidgets/FileUpload.php:

1. In getFileRecord(), replace $this->getRelationModel()->find(post('file_id')) with $this->getRelationObject()->withDeferred($this->sessionKey)->find(post('file_id')).
2. In onSortAttachments(), filter the posted sortOrder ids to those returned by $this->getRelationObject()->withDeferred($this->sessionKey)->pluck($keyName) before calling setSortableOrder().

Impact

Affected versions of Winter CMS did not validate the handler name submitted through the form postback mechanism (_handler POST field) in the same way as AJAX requests (X_WINTER_REQUEST_HANDLER header). The AJAX path validates that handler names match the on[A-Z][\w+]* pattern, but the postback path passed the handler name directly to the handler dispatcher with no validation.

This allowed an authenticated backend user to call any method on a controller — including action-prefixed, protected, and private methods — by submitting a crafted POST request with a _handler field, as long as the controller either:

• Contains a publicly available action via the $publicActions property, or
• Degrades or removes the $requiredPermissions check in its constructor based on a condition

The backend's own Users controller was affected by the second scenario: it set $requiredPermissions to null for the myaccount action, allowing any authenticated backend user to access the controller without the backend.manage_users permission. Combined with the postback bypass, this allowed calling controller methods such as update_onDelete, update_onRestore, update_onUnsuspendUser, and update_onManualPasswordReset with attacker-controlled parameters.

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 security issue, an attacker would need access to the Backend with a user account with any level of access.

The Winter CMS maintainers strongly recommend that all Winter CMS sites that have any reliance on the roles & permissions system to update immediately. Security fixes have been backported to all major versions of Winter (1.0, 1.1, and 1.2).

Patches

The postback handler path now validates handler names using the same rules as the AJAX path. The My Account functionality has been moved to a dedicated controller that does not expose user management methods. Defence in depth has been applied at the model level to prevent unauthorized user record modifications regardless of the entry point.

This security issue has been fixed as of v1.2.13.

Workarounds

If users cannot upgrade, they may apply the following changes to their Winter CMS installation manually to resolve this issue:

1. In modules/backend/classes/Controller.php, validate the _handler POST field against the on[A-Z][\w+]* pattern before passing it to runAjaxHandler().
2. In modules/backend/controllers/Users.php, remove the conditional that sets $requiredPermissions to null for the myaccount action.

Impact

The Backend Filter widget (Backend\Widgets\Filter) is vulnerable to SQL injection through the numberrange scope type when the scope is configured with a conditions key. An authenticated backend user with access to a list view containing a vulnerable filter scope can inject arbitrary SQL via the filter's AJAX handler, potentially gaining read access to the full database contents.

To exploit this, an attacker must have a valid backend account with access to a list view where a third-party plugin has registered a numberrange filter scope using the conditions configuration key. No built-in Winter CMS backend views use this scope type and configuration combination, so a vanilla installation without plugins is not exploitable.

Patches

This issue has been fixed in Winter CMS v1.2.13.

Workarounds

If users cannot upgrade, they may apply commit https://github.com/wintercms/winter/commit/50713de95adf5298536d93f4d999652525d36d43 to your Winter CMS installation manually to resolve this issue.

Impact

Users with the backend.manage_branding ("Customize the back-end") permission can provide custom CSS through Settings → Customize Backend → Styles that is compiled through the LESS CSS parser and rendered on every backend page. Previously, the compiled output was not sanitized, which could have allowed a stored XSS attack.

Although this is a valid security issue, it's important to note that its severity is relatively low. To exploit the vulnerability, an attacker would already need to have trusted access to the Winter CMS backend with a specific administrative permission. The Winter CMS maintainers recommend that the backend.manage_branding permission only be granted to trusted administrators and developers.

A related issue exists in the custom styles field at Settings → Editor Settings → Markup Styles (backend.manage_editor permission), which uses the same rendering mechanism and is addressed separately.

All users are advised to update to the latest version to ensure their systems remain secure.

Patches

This issue has been patched in v1.2.13.

Workarounds

Apply https://github.com/wintercms/winter/commit/d28f0b9474af79cfaa80eeb9d691f7a7c4469720 manually if unable to upgrade to v1.2.13.

Resources

• CVE-2025-61676 (identical vulnerability in October CMS, patched in v3.7.13 and v4.0.12)

Impact

Affected versions of Winter CMS allowed authenticated backend users to escalate their accounts level of access to the system by modifying the roles / permissions assigned to their account through specially crafted requests to the backend while logged in.

To actively exploit this security issue, an attacker would need access to the Backend with a user account with any level of access.

The Winter CMS maintainers strongly recommend that all Winter CMS sites that have any reliance on the roles & permissions system to update immediately. Security fixes have been backported to all major versions of Winter (1.0, 1.1, and 1.2).

Patches

Multiple fixes and defence in depth has been applied to prevent current and future privilege escalation attacks at the lowest level possible.

This security issue has been fixed as of https://wintercms.com/releases/v1.0.477, https://wintercms.com/releases/v1.1.12, https://wintercms.com/releases/v1.2.12.

Workarounds

If you cannot upgrade, you may apply the changes from the releases to your Winter CMS installation manually to resolve this issue.

Impact

Affected versions of Winter CMS render the search query parameter without HTML encoding inside a <script type="text/template"> block in the backend Table widget partial (modules/backend/widgets/table/partials/_table.php):

value="<?= get('search') ?>"

<script> is an HTML raw-text context, so the surrounding value="…" attribute quoting is not a parser boundary. A literal </script> in the query string terminates the template element early, and everything after it is parsed as ordinary markup in the backend document.

Any backend page rendering a Table or DataTable widget is a sink. The value is read from the global request through the get() helper, which — unlike post() — is not restricted by HTTP method, so a plain top-level GET navigation is sufficient. The template is also emitted unconditionally by the partial, so widgets using the default searching: false configuration are equally affected.

In Winter core the reachable route is the Editor Settings form (/backend/system/settings/update/winter/backend/editor), which renders six datatable fields and is gated by backend.manage_editor — assigned by default to the built-in Developer role. Third-party plugins using the datatable form widget, or the Table widget directly, expose the same sink on their own pages.

An attacker who induces a signed-in backend user to follow a crafted link executes script in that user's authenticated backend origin. The injected script can read the CSRF token published in the backend layout's <meta name="csrf-token"> element and issue credentialed requests as the victim, bounded only by that user's permissions. Because the core sink requires backend.manage_editor, the practical victim is a Developer-role user or superuser — who can edit CMS templates, so script running in that session can chain to server-side code execution.

This is not a permission bypass: the victim must already be authorised for the page, and the attacker gains no permission the victim does not hold.

To actively exploit this issue, an attacker needs no account of their own, but does need an authenticated backend user with access to a page rendering a Table or DataTable widget to follow an attacker-supplied link.

Patches

The search value is now HTML-encoded on output, matching every other value rendered by the same partial and the equivalent handling in the backend Search widget (modules/backend/widgets/search/partials/_search.php):

value="<?= e(get('search')); ?>"

This removes the raw-text terminator: the browser can no longer encounter an attacker-supplied literal </script> while tokenising the document. The template is subsequently parsed once by jQuery when the toolbar is built, so an encoded payload resolves to an inert attribute string rather than markup.

Regression coverage was added in modules/backend/tests/widgets/TableSearchEscapingTest.php, covering plain, mixed-case (</ScRiPt>) and whitespace-bearing (</script >) terminators, both searching states, and preservation of ordinary and Unicode search text.

This security issue has been fixed in v1.2.14.

Workarounds

If you cannot upgrade, apply https://github.com/wintercms/winter/commit/1b6397654124fb44a6abf6f3782b6a1d746cef14 manually — in modules/backend/widgets/table/partials/_table.php, change:

value="<?= get('search') ?>"

to:

value="<?= e(get('search')); ?>"

A restrictive Content Security Policy served at the web server or reverse proxy can reduce practical exploitability, but it is not a substitute for the fix: Winter's backend ships inline scripts, so a policy permissive enough to run the backend may still permit an injected execution primitive.

References

Credit to Awwader (@NRAwwad) for reporting the issue.

For more information

If you have any questions or comments about this advisory:

• Email us at hello@wintercms.com

Impact

Affected versions of Winter CMS allow a backend AJAX handler to be invoked by a plain top-level GET navigation with no CSRF token. Backend\Classes\Controller::actionExists() accepted any public method on a controller as a page action, so handler-shaped names were never reserved from URL dispatch: an authenticated and authorized request to /backend/system/eventlogs/index_onEmptyLog reached the handler of the same name and truncated the system event log. Backend paths are routed through Route::any, and CSRF validation is skipped for HEAD, GET and OPTIONS requests.

The default SameSite=Lax session cookie is sent on top-level cross-site navigation, so a link on an attacker-controlled page is sufficient — no form, no script and no token. Handler arguments are taken from URL path segments, so the attacker also chooses the target record. Affected handlers across the backend, cms and system modules cover log truncation, resetting settings to their defaults, altering backend user state, and deleting CMS templates. None of them disclose data to the attacker or write attacker-controlled content, so the impact is destructive and state-changing rather than confidential.

To actively exploit this issue, an attacker would need no account of their own, but would need an authenticated backend user holding the relevant permission to follow an attacker-supplied link. The permissions guarding the affected handlers, system.access_logs included, are by default assigned only to the built-in Developer role.

Patches

Page-action dispatch is now restricted to all-lowercase method names, which reserves handler-shaped names (onFoo, index_onFoo) from being reached by URL. AJAX dispatch is unchanged: handlers continue to work over POST with the X-WINTER-REQUEST-HANDLER header exactly as before, and need no changes.

IMPORTANT: This fix includes a breaking change to backend action routing. A public controller method used as a page action must now be named in lowercase — coming_soon() rather than comingSoon() — and dashed URLs are normalised to snake_case, so /coming-soon now resolves to coming_soon() instead of comingSoon(). Plugins with a camelCase page action should rename the method and its view file to match; the published URL does not need to change. Core is unaffected, and a survey of the plugin ecosystem found the change affects only a small number of plugins.

This security issue has been fixed in v1.2.14.

Workarounds

If you cannot upgrade, apply https://github.com/wintercms/winter/commit/353b23804dee2acf49fca996c72637040446824f manually.

As an interim mitigation, set 'same_site' => 'strict' in config/session.php. A strict session cookie is not sent on cross-site top-level navigation, which prevents the victim's session accompanying an attacker's link. Review this against any single sign-on or inbound-link flows into your backend first, as it also affects legitimate cross-site entry.

References

Credit to Awwader (@NRAwwad) for reporting the issue.

For more information

If you have any questions or comments about this advisory:

• Email us at hello@wintercms.com

Impact

Users with the backend.manage_branding ("Customize the back-end") or backend.manage_editor ("Manage global code editor preferences") permission can provide custom CSS through Settings → Customize Backend → Styles or Settings → Editor Settings → Markup Styles that is compiled through the LESS CSS parser and rendered on every backend page.

v1.2.13 addressed CVE-2026-32257 and CVE-2026-32258 by applying strip_tags() to the compiled output of BrandSetting::renderCss() and EditorSetting::renderCss(). That fix was incomplete. Both methods cache the raw compiler output with Cache::forever() and applied strip_tags() only to the value returned on a cache miss, so every subsequent cache hit returned the unsanitized value directly into the backend <style> element. The first page render after saving therefore appears sanitized while priming an unsafe cache entry, and the stored XSS remains exploitable from the second render onwards.

Because the custom styles partial is included by both the standard backend layout head and the backend authentication layout, an injected payload also renders on the unauthenticated backend sign-in, password restore, and password reset pages.

Although this is a valid security issue, it's important to note that its severity is relatively low. To exploit the vulnerability, an attacker would already need to have trusted access to the Winter CMS backend with a specific administrative permission. The Winter CMS maintainers recommend that the backend.manage_branding and backend.manage_editor permissions only be granted to trusted administrators and developers.

All users are advised to update to the latest version to ensure their systems remain secure.

Patches

This issue has been patched in v1.2.14. The renderCss() methods now apply strip_tags() to the cached value when it is read back, which also neutralizes any cache entry that was poisoned before upgrading.

The backend.manage_editor and backend.manage_default_dashboard permissions have additionally been given warning comments in the permission editor, matching the existing warning on backend.manage_branding.