WINTER/WN-BACKEND-MODULE · CVE-2026-125338 · Package
FIX → 1.2.14
Winter CMS caches unsanitized custom CSS from the Brand and Editor settings, so the strip_tags() fix only applies on cache misses. A user with the branding or editor permission can store a payload that runs in every backend page, including the sign-in and password reset pages.
first public Aug 19, 2026 · 2 sources
Could this affect your app?
Free first check from your website. Connect your repo for the full answer.
Sites running Winter CMS 1.2.13 or earlier with a backend where users can edit branding or editor styles. The attacker must already hold the backend.manage_branding or backend.manage_editor permission, so sites that grant these only to trusted administrators face low risk. Installations that do not use the backend styles settings or that upgraded to 1.2.14 are not exposed.
Not affected if no-backend-style-permissions, version-1.2.14-or-later
Who cares laravel, php, self-hosted, winter-cms
composer show winter/wn-backend-module; affected versions are 1.2.13 and below.backend.manage_branding or backend.manage_editor permissions.Upgrade to 1.2.14
Users with the backend.manage_branding ("Customize the back-end") or backend.manage_editor ("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 strip_tags() 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 strip_tags() 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.
Check it with your coding agent
It reads this page and tells you if your code is affected.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
winter/wn-backend-module to 1.2.14Although 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.manage_branding and backend.manage_editor 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.
This issue has been patched in v1.2.14. The renderCss() methods now apply strip_tags() to the cached value when it is read back, which also neutralizes any cache entry that was poisoned before upgrading.
The backend.manage_editor and backend.manage_default_dashboard permissions have additionally been given warning comments in the permission editor, matching the existing warning on backend.manage_branding.
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.
This page as .md · .json · CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:N/I:H/A:N
GitHub Advisory Database, CC-BY 4.0 · NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.