GHSA-hq84-x37p-j6q5

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