GHSA-HQ84-X37P-J6Q5: Reflected Cross-Site Scripting in Winter CMS Backend Table Widget

The vulnerability affects the backend Table widget component in Winter CMS. This component is responsible for rendering interactive data grids, complete with search, filtering, and sorting utilities, which administrative users access inside the control panel.

The attack surface exists in the search input element located at modules/backend/widgets/table/partials/_table.php. Because this input is part of a template that is processed dynamically on the client side, the developers enclosed the markup in a script element of type text/template.

By leveraging the unique parsing rules that browsers apply to raw-text HTML elements, an unauthenticated attacker can craft a malicious hyperlink that targets this endpoint. If an authenticated administrator visits the link, arbitrary script commands run in their browser context, compromising the administrative session.

The root cause of this vulnerability lies in the combination of raw parameter reflection and browser HTML tokenization rules. The application retrieves the value of the search GET query parameter directly via the get('search') helper and embeds it into the value attribute of an HTML input tag.

To prevent the browser from rendering the toolbar controls on page load before the JavaScript framework initializes, the entire block is enclosed inside <script type="text/template">. According to the HTML5 specifications, <script> tags are treated as Raw Text Elements.

When the browser's parser encounters a Raw Text Element, it switches to the Script Data State. In this state, the parser does not recognize standard HTML attributes, single quotes, or double quotes as value boundaries. Instead, it scans the character stream exclusively for the literal ending sequence </script>. When an attacker passes a payload containing </script> inside the query string, the parser matches this sequence, closes the initial template block early, and treats the remaining payload as executable code.

The vulnerable code path is situated in the table partial file. Reviewing the difference between the vulnerable and patched versions highlights how the vulnerability was introduced and resolved.

Below is the code before the patch:

<!-- Vulnerable Code -->
<input 
    placeholder="<?= e(trans('backend::lang.list.search_prompt')) ?>"
    name="search"
    id="search"
    value="<?= get('search') ?>"
    type="text"
    autocomplete="off"
    class="table-search-input form-control icon search" />

In the block above, get('search') retrieves the raw parameter and emits it directly. Below is the code after the patch:

<!-- Patched Code -->
<input 
    placeholder="<?= e(trans('backend::lang.list.search_prompt')) ?>"
    name="search"
    id="search"
    value="<?= e(get('search')); ?>"
    type="text"
    autocomplete="off"
    class="table-search-input form-control icon search" />

The patch routes the output through the e() helper function, which runs htmlspecialchars() under the hood. This converts dangerous characters such as < and > into their equivalent HTML entities (< and >). When the browser's parser scans the script block, it sees </script> instead of the literal closing sequence, preventing the early termination of the raw-text element.

Exploitation requires targeting an administrative user who has access to the backend table interface. The attacker must construct a URL that points to a backend controller utilizing the table widget and includes the malicious payload in the query string.

A verified exploitation payload uses the raw-text terminator sequence combined with a secondary script block:

</script><script>alert(document.cookie)</script>

When encoded and appended to the target URL, the full request looks as follows:

https://example.com/backend/acme/plugin/items?search=%3C%2Fscript%3E%3Cscript%3Ealert%28document.cookie%29%3C%2Fscript%3E

Once the administrator loads this link, the browser tokenizes the response, terminates the template block at the first occurrence of </script>, and executes the secondary script block immediately, allowing the attacker to read the session cookie or perform actions on behalf of the administrator.

The impact of this vulnerability is classified as Medium, reflecting the classic risks associated with session hijacking and client-side privilege escalation. Because the payload executes within the administrative console of Winter CMS, the script runs with the authorization level of the logged-in administrator.

An attacker exploiting this vulnerability can perform unauthorized state modifications, steal session identifiers, or inject persistent backdoors into other sections of the content management system.

The vector breakdown under CVSS v3.1 is CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N. While exploitation requires user interaction to click the crafted link, the lack of prior authorization requirements and the potential for complete control over the CMS backend emphasize the need for immediate remediation.

To fully resolve the vulnerability, administrators must update Winter CMS to version v1.2.14 or higher. This update applies the escaping helper systematically across the affected templates.

If an immediate upgrade of the framework is not feasible, the vulnerability can be mitigated manually by applying the patch to the template partial at modules/backend/widgets/table/partials/_table.php on line 44. Ensure that the raw call to get('search') is wrapped inside the escaping helper e() as shown in the code analysis.

In addition, deploying a Web Application Firewall (WAF) with rules that detect and block raw closing HTML tags inside URL parameters can act as a temporary workaround until the patch is successfully applied.