GHSA-hq84-x37p-j6q5: Winter: Reflected XSS through the search query parameter in the backend Table widget

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.