Executive brief
Winter CMS's backend styling system allows administrators with branding or editor permissions to inject custom CSS that is cached and rendered on every backend page, including unauthenticated login pages. A previous patch applied sanitization only to the first cache retrieval, leaving subsequent cached copies vulnerable to cross-site scripting attacks. An attacker with administrative styling permissions could execute arbitrary JavaScript in the context of backend users and unauthenticated sign-in pages.
Technical details
This vulnerability is a stored cross-site scripting (XSS) flaw in Winter CMS's BrandSetting::renderCss() and EditorSetting::renderCss() methods. The root cause is incomplete sanitization of LESS CSS compiler output: the raw compiled CSS is cached via Cache::forever() without sanitization, and strip_tags() is applied only when the cached value is first retrieved on a cache miss. Every subsequent cache hit returns the unsanitized HTML/CSS directly into the backend <style> element, allowing injected payloads to execute from the second page render onwards. The vulnerability requires high privileges (backend.manage_branding or backend.manage_editor permissions) and user interaction (viewing the affected page), but the impact is severe because the custom styles are rendered on all backend pages and also on unauthenticated sign-in, password restore, and password reset pages. The fix, released in v1.2.14, applies strip_tags() to the cached value when it is read back, neutralizing both new and previously poisoned cache entries.
Affected products
- Winter wn-backend-module <= 1.2.13
Timeline
- 2026-08-20: disclosed: Advisory published by Winter CMS
- 2026-08-20: patched: Fix released in v1.2.14