GHSA-5cwr-5jxg-pcf6: XSS

Published Aug 20, 2026
·
Updated

Impact

Users with the backend.managebranding ("Customize the back-end") or backend.manageeditor ("Manage global code editor preferences") permission can provide custom CSS through Settings → Customize Backend → Styles or Settings → Editor Settings → Markup Styles that is compiled through the LESS CSS parser and rendered on every backend page.

v1.2.13 addressed CVE-2026-32257 and CVE-2026-32258 by applying striptags() to the compiled output of BrandSetting::renderCss() and EditorSetting::renderCss(). That fix was incomplete. Both methods cache the raw compiler output with Cache::forever() and applied striptags() only to the value returned on a cache miss, so every subsequent cache hit returned the unsanitized value directly into the backend <style> element. The first page render after saving therefore appears sanitized while priming an unsafe cache entry, and the stored XSS remains exploitable from the second render onwards.

Because the custom styles partial is included by both the standard backend layout head and the backend authentication layout, an injected payload also renders on the unauthenticated backend sign-in, password restore, and password reset pages.

Although this is a valid security issue, it's important to note that its severity is relatively low. To exploit the vulnerability, an attacker would already need to have trusted access to the Winter CMS backend with a specific administrative permission. The Winter CMS maintainers recommend that the backend.managebranding and backend.manageeditor permissions only be granted to trusted administrators and developers.

All users are advised to update to the latest version to ensure their systems remain secure.

Patches

This issue has been patched in v1.2.14. The renderCss() methods now apply striptags() to the cached value when it is read back, which also neutralizes any cache entry that was poisoned before upgrading.

The backend.manageeditor and backend.managedefaultdashboard permissions have additionally been given warning comments in the permission editor, matching the existing warning on backend.managebranding.

Workarounds

Apply https://github.com/wintercms/winter/commit/c95d780ab54f3a3f74a94ae1667bf12b3c549d5d manually if unable to upgrade to v1.2.14.

Clearing the application cache removes an already-poisoned entry, but it will be recreated on the next backend page render unless the patch is applied.

References

- CVE-2026-32257 / GHSA-v7cf-8gh9-gxmj (Stored XSS through Brand Settings custom styles, incompletely patched in v1.2.13) - CVE-2026-32258 / GHSA-vgp4-2fc4-qff2 (Stored XSS through Editor Settings custom styles, incompletely patched in v1.2.13) - CVE-2025-61674 and CVE-2025-61676 (identical vulnerability in October CMS, patched in v3.7.13 and v4.0.12)

Affected Software

1 affected componentFixes available
composer/winter/wn-backend-module<=1.2.13
1.2.14

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade composer/winter/wn-backend-module to a version that resolves this vulnerability.

    Fixed in 1.2.14
  2. Upgrade

    Upgrade Winter CMS to a version that resolves this vulnerability.

    Fixed in 3.7.13
  3. Upgrade

    Upgrade Winter CMS to a version that resolves this vulnerability.

    Fixed in 4.0.12
  4. Upgrade

    Upgrade Winter CMS to a version that resolves this vulnerability.

    Fixed in 1.2.14
  5. Configuration

    Limit who can access back-end custom branding/styles by only granting the `backend.manage_branding` permission to trusted administrators and developers.

    Winter CMS permissions backend.manage_branding = grant only to trusted administrators and developers
  6. Configuration

    Limit who can access back-end editor/markup styles by only granting the `backend.manage_editor` permission to trusted administrators and developers.

    Winter CMS permissions backend.manage_editor = grant only to trusted administrators and developers
  7. Operational

    Clear the application cache to remove any already-poisoned cached `<style>` content; otherwise it will be recreated on the next backend page render unless the patch (v1.2.14) is applied.

Event History

Aug 20, 2026
Advisory Published
via GitHub·06:44 PM
Data Sourced
via GitHub·06:44 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

Who can introduce a malicious payload?

A user needs either the backend.manage_branding permission or the backend.manage_editor permission. They can supply custom CSS through the backend Styles or Markup Styles settings.

2

Which users or pages can receive the injected content?

The compiled styles are rendered on every backend page. They are also included in the backend authentication layout, affecting the backend sign-in and password restore pages.

3

Does the sanitization in v1.2.13 prevent exploitation?

No. The sanitization is applied only to the value returned when the cache is first populated, while the raw compiler output is stored with Cache::forever() and returned unsanitized on later cache hits.

4

How can an administrator identify whether the issue may already be active?

Review custom CSS configured in Customize Backend → Styles and Editor Settings → Markup Styles, especially changes made by accounts with the relevant permissions. An unsafe compiler output that has been cached can be served starting with the second render after the style was saved.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203