GHSA-HQ84-X37P-J6Q5

Winter: Reflected XSS through the search query parameter in the backend Table widget

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

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

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.

Untrusted input is rendered as active markup in a victim's browser, which can run script in their session. Typical impact: session or credential theft, and actions taken as the user.

GHSA-HQ84-X37P-J6Q5 has a CVSS score of 4.5 (Medium). The vector is network-reachable, high privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (1.2.14); upgrading removes the vulnerable code path.

Kodem intelligence

Already deployed Kodem?

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.

1. What is GHSA-HQ84-X37P-J6Q5? GHSA-HQ84-X37P-J6Q5 is a medium-severity cross-site scripting (XSS) vulnerability in winter/wn-backend-module (composer), affecting versions >= 1.0.420, <= 1.2.13. It is fixed in 1.2.14. Untrusted input is rendered as active markup in a victim's browser, which can run script in their session.
2. How severe is GHSA-HQ84-X37P-J6Q5? GHSA-HQ84-X37P-J6Q5 has a CVSS score of 4.5 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of winter/wn-backend-module are affected by GHSA-HQ84-X37P-J6Q5? winter/wn-backend-module (composer) versions >= 1.0.420, <= 1.2.13 is affected.
4. Is there a fix for GHSA-HQ84-X37P-J6Q5? Yes. GHSA-HQ84-X37P-J6Q5 is fixed in 1.2.14. Upgrade to this version or later.
5. Is GHSA-HQ84-X37P-J6Q5 exploitable, and should I be worried? Whether GHSA-HQ84-X37P-J6Q5 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether GHSA-HQ84-X37P-J6Q5 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix GHSA-HQ84-X37P-J6Q5? Upgrade winter/wn-backend-module to 1.2.14 or later.

Other vulnerabilities in winter/wn-backend-module