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

> Reflected XSS in Winter CMS backend allows attackers to execute scripts in authenticated sessions, potentially leading to code execution via template editing.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Any signed-in user
- **Attackable:** Over the internet
- **Victim action needed:** A user has to click or open something
- **Fix available:** Yes
- **Published:** 20 Aug 2026

## What is GHSA-hq84-x37p-j6q5?

GHSA-hq84-x37p-j6q5 is a cross-site scripting vulnerability in winter/wn-backend-module, published on 20 Aug 2026. Any signed-in user can exploit it over the network, and only if a user opens a file or follows a link.

### Official description

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

```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](https://github.com/wintercms/winter/commit/1b6397654124fb44a6abf6f3782b6a1d746cef14).

### Workarounds

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

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

to:

```php
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](https://github.com/NRAwwad)) for reporting the issue.

### For more information

If you have any questions or comments about this advisory:
- Email us at [hello@wintercms.com](mailto:hello@wintercms.com)

## Which versions are affected by GHSA-hq84-x37p-j6q5?

2 open source packages ship an affected version, including winter/wn-backend-module.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `winter/wn-backend-module` | Packagist | From 1.0.420 | 1.2.14 |
| `winter/wn-backend-module` | Packagist | From 1.0.420 | 1.2.14 |

## How do I fix GHSA-hq84-x37p-j6q5?

Upgrade winter/wn-backend-module to 1.2.14 or later.

## Is GHSA-hq84-x37p-j6q5 being exploited?

There is no known exploitation of GHSA-hq84-x37p-j6q5 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-hq84-x37p-j6q5 and fix it if it is affected.

What it is: GHSA-hq84-x37p-j6q5 is a cross-site scripting vulnerability in winter/wn-backend-module, published on 20 Aug 2026. Any signed-in user can exploit it over the network, and only if a user opens a file or follows a link.
Exploitation: There is no known exploitation of GHSA-hq84-x37p-j6q5 in the wild and no public exploit code.

Affected packages and fixed versions:
- winter/wn-backend-module (Packagist): affected from 1.0.420; fixed in 1.2.14
- winter/wn-backend-module (Packagist): affected from 1.0.420; fixed in 1.2.14

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/GHSA-hq84-x37p-j6q5/ (Markdown: https://insights.sbomify.com/GHSA-hq84-x37p-j6q5/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-hq84-x37p-j6q5

---
From sbomify Insights: https://insights.sbomify.com/GHSA-hq84-x37p-j6q5/
Summaries are generated and may contain mistakes; the official description above is the record.