{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.2.13"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "winter/wn-backend-module"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.420"
            },
            {
              "fixed": "1.2.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-79"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-20T18:45:04Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nAffected versions of Winter CMS render the `search` query parameter without HTML encoding inside a `\u003cscript type=\"text/template\"\u003e` block in the backend Table widget partial (`modules/backend/widgets/table/partials/_table.php`):\n\n```php\nvalue=\"\u003c?= get(\u0027search\u0027) ?\u003e\"\n```\n\n`\u003cscript\u003e` is an HTML raw-text context, so the surrounding `value=\"\u2026\"` attribute quoting is not a parser boundary. A literal `\u003c/script\u003e` in the query string terminates the template element early, and everything after it is parsed as ordinary markup in the backend document.\n\nAny backend page rendering a Table or DataTable widget is a sink. The value is read from the global request through the `get()` helper, which \u2014 unlike `post()` \u2014 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.\n\nIn 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` \u2014 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.\n\nAn attacker who induces a signed-in backend user to follow a crafted link executes script in that user\u0027s authenticated backend origin. The injected script can read the CSRF token published in the backend layout\u0027s `\u003cmeta name=\"csrf-token\"\u003e` element and issue credentialed requests as the victim, bounded only by that user\u0027s permissions. Because the core sink requires `backend.manage_editor`, the practical victim is a Developer-role user or superuser \u2014 who can edit CMS templates, so script running in that session can chain to server-side code execution.\n\nThis 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.\n\nTo 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.\n\n### Patches\n\nThe `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`):\n\n```php\nvalue=\"\u003c?= e(get(\u0027search\u0027)); ?\u003e\"\n```\n\nThis removes the raw-text terminator: the browser can no longer encounter an attacker-supplied literal `\u003c/script\u003e` 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.\n\nRegression coverage was added in `modules/backend/tests/widgets/TableSearchEscapingTest.php`, covering plain, mixed-case (`\u003c/ScRiPt\u003e`) and whitespace-bearing (`\u003c/script \u003e`) terminators, both `searching` states, and preservation of ordinary and Unicode search text.\n\nThis security issue has been fixed in [v1.2.14](https://github.com/wintercms/winter/commit/1b6397654124fb44a6abf6f3782b6a1d746cef14).\n\n### Workarounds\n\nIf you cannot upgrade, apply https://github.com/wintercms/winter/commit/1b6397654124fb44a6abf6f3782b6a1d746cef14 manually \u2014 in `modules/backend/widgets/table/partials/_table.php`, change:\n\n```php\nvalue=\"\u003c?= get(\u0027search\u0027) ?\u003e\"\n```\n\nto:\n\n```php\nvalue=\"\u003c?= e(get(\u0027search\u0027)); ?\u003e\"\n```\n\nA 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\u0027s backend ships inline scripts, so a policy permissive enough to run the backend may still permit an injected execution primitive.\n\n### References\n\nCredit to Awwader ([@NRAwwad](https://github.com/NRAwwad)) for reporting the issue.\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n- Email us at [hello@wintercms.com](mailto:hello@wintercms.com)",
  "id": "GHSA-hq84-x37p-j6q5",
  "modified": "2026-08-20T18:45:04Z",
  "published": "2026-08-20T18:45:04Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/wintercms/winter/security/advisories/GHSA-hq84-x37p-j6q5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/wintercms/winter/commit/1b6397654124fb44a6abf6f3782b6a1d746cef14"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/wintercms/winter"
    },
    {
      "type": "WEB",
      "url": "https://github.com/wintercms/winter/releases/tag/v1.2.14"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Winter: Reflected XSS through the search query parameter in the backend Table widget"
}