WINTER/WN-BACKEND-MODULE · CVE-2026-125340 · Package
FIX → 1.2.14
The backend Table widget in Winter CMS prints the search query parameter without HTML encoding inside a script template block, so a crafted link can break out and run script. An attacker who gets a signed-in backend user to open the link can run script in that user's backend session and act with their permissions.
first public Aug 19, 2026 · 2 sources
Could this affect your app?
Free first check from your website. Connect your repo for the full answer.
Any Winter CMS install whose backend pages render a Table or DataTable widget is exposed, and the Editor Settings form in core is a reachable example. The practical victims are backend users with access to those pages, most likely Developer-role users or superusers, because the core sink requires backend.manage_editor. Sites that do not run the backend module at the affected versions can skip it.
Not affected if no-backend-table-widget, version-outside-range
Who cares backend-widgets, php, self-hosted, winter-cms
composer show winter/wn-backend-module and see whether it falls in >= 1.0.420, <= 1.2.13.modules/backend/widgets/table/partials/_table.php and see whether the search value is printed with get('search') and no e() call.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 configuration are equally affected.
Check it with your coding agent
It reads this page and tells you if your code is affected.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
Upgrade to 1.2.14
winter/wn-backend-module: upgrade to 1.2.14.e() in modules/backend/widgets/table/partials/_table.php.searching: falseIn 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.
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.
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.
Credit to Awwader (@NRAwwad) for reporting the issue.
If you have any questions or comments about this advisory:
This page as .md · .json · CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:N/I:H/A:N
GitHub Advisory Database, CC-BY 4.0 · NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.