Every CVE Search/ Get API key

CVE-2026-125338

Winter: Stored XSS through cached Brand Settings and Editor Settings custom styles

4.5 MediumFix available

Impact

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.

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.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.

Patches

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.

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)

Attack profile

How easy it is to exploit

Attack vector
Network
Complexity
Low
Privileges needed
High
User interaction
Required

What an attacker can affect

Confidentiality
None
Integrity
High
Availability
None

What each source reports

GitHub Advisories Score usedGHSA-5cwr-5jxg-pcf6 4.5

Winter: Stored XSS through cached Brand Settings and Editor Settings custom styles

Impact

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.

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.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.

Patches

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.

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)
Record
GHSA-5cwr-5jxg-pcf6
CVSS 3.1
4.5 MediumCVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:N/I:H/A:N
Weakness
CWE-79
Updated
2026-11-10
OSVGHSA-5cwr-5jxg-pcf6 4.5

Winter: Stored XSS through cached Brand Settings and Editor Settings custom styles

Impact

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.

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.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.

Patches

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.

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)
Record
GHSA-5cwr-5jxg-pcf6
CVSS 3.1
4.5 MediumCVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:N/I:H/A:N
Weakness
CWE-79
Updated
2026-11-10

Affected packages

Affected packages
PackageAffectedFixed
winter/wn-backend-module
Packagist
through 1.2.13
1.2.14
winter/wn-backend-module
Packagist
before 1.2.14, plus listed versions
v1.0.473v1.0.474v1.0.475v1.1.10v1.1.11
Show 22 moreShow less
v1.1.2v1.1.3v1.1.4v1.1.5v1.1.6v1.1.7v1.1.8v1.1.9v1.2.0v1.2.1v1.2.10v1.2.11v1.2.12v1.2.13v1.2.2v1.2.3v1.2.4v1.2.5v1.2.6v1.2.7v1.2.8v1.2.9
1.2.14

History

History
RecordedChangedSources
aliases, facts, idGitHub Advisories
first indexedGitHub Advisories, OSV

Dates are when Every CVE recorded each change. Upstream dates may differ.

In short

CVE-2026-125338 is a medium vulnerability (CVSS 4.5) in winter/wn-backend-module, published August 20, 2026. No source lists public exploit code. Fixed in winter/wn-backend-module 1.2.14.

References

MoveEnter Open