Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
15 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact Affected versions of Winter CMS render the search query parameter without HTML encoding inside a <script type="text/template" block in the backend Table widget partial (modules/backend/widgets/table/partials/table.php): <script is an HTML raw-text context, so the surrounding value="…" attribute quoting is not a parser boundary. A literal </script in the query string terminates the template element early, and everything after it is parsed as ordinary markup in the backend document. Any backend page rendering a Table or DataTable widget is a sink. The value is read from the global request through the get() helper, which — unlike post() — 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. In Winter core the reachable route is the Editor Settings form (/backend/system/settings/update/winter/backend/editor),…
Recommended action: Upgrade to 1.2.14 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Affected versions of Winter CMS allow a backend AJAX handler to be invoked by a plain top-level GET navigation with no CSRF token. Backend\Classes\Controller::actionExists() accepted any public method on a controller as a page action, so handler-shaped names were never reserved from URL dispatch: an authenticated and authorized request to /backend/system/eventlogs/indexonEmptyLog reached the handler of the same name and truncated the system event log. Backend paths are routed through Route::any, and CSRF validation is skipped for HEAD, GET and OPTIONS requests. The default SameSite=Lax session cookie is sent on top-level cross-site navigation, so a link on an attacker-controlled page is sufficient — no form, no script and no token. Handler arguments are taken from URL path segments, so the attacker also chooses the target record. Affected handlers across the backend, cms and system modules cover log truncation, resetting settings to their defaults, altering backend user state,…
Recommended action: Upgrade to 1.2.14 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 1.2.14 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Affected versions of Winter CMS did not enforce the ImportExportController behavior's granular access control on the handlers that actually perform the work. The behavior supports per-operation access control through the import[permissions] and export[permissions] configuration keys, enforced by userHasAccess(). That check was applied only to the import() and export() page actions. Backend\Classes\Controller::execAjaxHandlers() dispatches AJAX handlers and returns before execPageAction() runs, and the behavior binds its import and export form widgets in its constructor on every request to the controller. The handlers were therefore fully functional without the gated page action ever executing, and none of them carried the check: - onImport() — reaches $model-import() with attacker-supplied column mappings - onImportLoadForm() - onImportLoadColumnSampleForm() - onExport() — reaches $model-export() - onExportLoadForm() - download() — streams a completed export file An…
Recommended action: Upgrade to 1.2.14 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Backend\Controllers\MyAccount, introduced in v1.2.13, declares an empty $requiredPermissions array so that any authenticated backend user can manage their own account. It implements the FormController behavior, which exposes three routable actions — create, update and preview — that each take a record id from the URL. index() passes the authenticated user's own id to the behavior, but the inherited actions were left routable and formFindModelObject() was not scoped, so a caller-supplied id resolved against an unscoped Backend\Models\User query: preview disclosed the target user's first name, last name, login, email address and avatar; update was equally routable and additionally disclosed role, group membership, superuser flag and throttle state. Password controls render a mask, so no credential material was exposed. Backend user ids are sequential and trivially enumerated, and as these are GET actions no CSRF token is involved. The behavior's AJAX handlers (createonSave,…
Recommended action: Upgrade to 1.2.14 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Backend\Widgets\Lists::evalImageTypeValue() interpolated the resolved image URL into a single-quoted src attribute without escaping it. Where a list column of type image rendered an attacker-influenced value, that value could break out of the attribute and inject arbitrary attributes — including event handlers — into the backend list, executing in the session of whichever backend user viewed it. Winter core ships no image list column, so a default installation is unaffected. Exploitation requires a plugin that renders attacker-influenced values through one. The supported image sources are plugins, themes, the Media Library, the uploads directory, and Attach\File models; an arbitrary external URL is not among them. ImageResizer::filterGetUrl() returns the value it was given when it cannot resolve an image, however, so an unsupported value reached the attribute verbatim rather than being rejected. As with previous issues of this kind the severity is limited: an attacker must…
Recommended action: Upgrade to 1.2.14 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Affected versions of Winter CMS allow authenticated backend users with the following permissions to disclose arbitrary files readable by the PHP process by injecting @import (inline) "<path" directives into LESS source that the backend compiles. Four entry points share the same root cause: - Brand Settings BrandSetting.customcss field (backend.managebranding) — compiled inline into every backend page's <style block. - Editor Settings EditorSetting.htmlcustomstyles field (backend.manageeditor) — compiled inline into every backend page's <style block. - Mail Brand Settings MailBrandSetting colour-picker fields (system.managemailtemplates) — values are concatenated into LESS source via LessParser::ModifyVars() with no escaping, so any value the form validator does not reject can carry an @import directive. - Theme .less/.sass/.scss assets (cms.manageassets) — compiled through System\Classes\CombineAssets when served, with the same LessParser configuration. Both absolute paths and…
Recommended action: Upgrade to 1.2.13 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The backend FileUpload form widget trusted an attacker-controlled fileid POST parameter when resolving the attachment it operates on. The lookup (FileUpload::getFileRecord()) resolved the posted id against the global systemfiles table without verifying that the file belonged to the widget's own relation, parent record, or deferred-binding session. Any authenticated backend user who can reach a form containing a fileupload field — including the built-in My Account avatar field, which requires no specific backend permission — could therefore target a System\Models\File record belonging to another user or record and: - modify its title and description via onSaveAttachmentConfig, and - change its sortorder via onSortAttachments (which passed posted ids straight to setSortableOrder(), an unscoped UPDATE ... WHERE id = ?). The same unscoped lookup is reached by onLoadAttachmentConfig, onSaveAttachmentConfig, and onRemoveAttachment. Because all attachments share the single…
Recommended action: Upgrade to 1.2.13 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Affected versions of Winter CMS did not validate the handler name submitted through the form postback mechanism (handler POST field) in the same way as AJAX requests (XWINTERREQUESTHANDLER header). The AJAX path validates that handler names match the on[A-Z][\w+] pattern, but the postback path passed the handler name directly to the handler dispatcher with no validation. This allowed an authenticated backend user to call any method on a controller — including action-prefixed, protected, and private methods — by submitting a crafted POST request with a handler field, as long as the controller either: - Contains a publicly available action via the $publicActions property, or - Degrades or removes the $requiredPermissions check in its constructor based on a condition The backend's own Users controller was affected by the second scenario: it set $requiredPermissions to null for the myaccount action, allowing any authenticated backend user to access the controller without the…
Recommended action: Upgrade to 1.2.13 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The Backend Filter widget (Backend\Widgets\Filter) is vulnerable to SQL injection through the numberrange scope type when the scope is configured with a conditions key. An authenticated backend user with access to a list view containing a vulnerable filter scope can inject arbitrary SQL via the filter's AJAX handler, potentially gaining read access to the full database contents. To exploit this, an attacker must have a valid backend account with access to a list view where a third-party plugin has registered a numberrange filter scope using the conditions configuration key. No built-in Winter CMS backend views use this scope type and configuration combination, so a vanilla installation without plugins is not exploitable. Patches This issue has been fixed in Winter CMS v1.2.13. Workarounds If users cannot upgrade, they may apply commit https://github.com/wintercms/winter/commit/50713de95adf5298536d93f4d999652525d36d43 to your Winter CMS installation manually to resolve this…
Recommended action: Upgrade to 1.2.13 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Authenticated Backend Users with the backend.manageeditor ("Manage editor settings") permission can provide custom styles through Settings → Editor Settings → Markup Styles that are compiled through the LESS CSS parser and rendered on every backend page. Previously, the compiled output was not sanitized, which could have allowed a stored XSS attack. 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.manageeditor permission only be granted to trusted administrators and developers. A related issue exists in the custom CSS field at Settings → Customize Backend → Styles (backend.managebranding permission), which uses the same rendering mechanism and is addressed separately. All users are advised to update to the latest version…
Recommended action: Upgrade to 1.2.13 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Users with the backend.managebranding ("Customize the back-end") permission can provide custom CSS through Settings → Customize Backend → Styles that is compiled through the LESS CSS parser and rendered on every backend page. Previously, the compiled output was not sanitized, which could have allowed a stored XSS attack. 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 permission only be granted to trusted administrators and developers. A related issue exists in the custom styles field at Settings → Editor Settings → Markup Styles (backend.manageeditor permission), which uses the same rendering mechanism and is addressed separately. All users are advised to update to the latest version to ensure their…
Recommended action: Upgrade to 1.2.13 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Affected versions of Winter CMS allowed authenticated backend users to escalate their accounts level of access to the system by modifying the roles / permissions assigned to their account through specially crafted requests to the backend while logged in. To actively exploit this security issue, an attacker would need access to the Backend with a user account with any level of access. The Winter CMS maintainers strongly recommend that all Winter CMS sites that have any reliance on the roles & permissions system to update immediately. Security fixes have been backported to all major versions of Winter (1.0, 1.1, and 1.2). Patches Multiple fixes and defence in depth has been applied to prevent current and future privilege escalation attacks at the lowest level possible. This security issue has been fixed as of https://wintercms.com/releases/v1.0.477, https://wintercms.com/releases/v1.1.12, https://wintercms.com/releases/v1.2.12. Workarounds If you cannot upgrade, you may apply…
Recommended action: Upgrade to 1.2.12, 1.1.12 or 1.0.477 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Users with access to backend forms that include a ColorPicker FormWidget can provide a value that would then be included without further processing in the compilation of custom stylesheets via LESS. This had the potential to lead to a Local File Inclusion vulnerability. By default, only the Brand Settings (backend.managebranding) and Mail Brand Settings (system.managemailtemplates) forms both include the colorpicker formwidget and pass the provided value to be compiled in LESS, however it is also common for themes to include it on their Theme Customization (cms.managethemeoptions) form and it is technically possible for the values on that form to also be used in LESS compilation: https://wintercms.com/docs/v1.2/docs/themes/development#asset-compiler-variables. Patches This issue has been patched in v1.2.4. Workarounds Apply https://github.com/wintercms/winter/commit/5bc9257fe2bc47d8b786a1b1bf96bafad23d8ddd manually if unable to upgrade to v1.2.4.
Recommended action: Upgrade to 1.2.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Users with access to backend forms that include a ColorPicker FormWidget can provide a value that would then be rendered unescaped in the backend form, potentially allowing for a stored XSS attack. By default, only the Brand Settings (backend.managebranding) and Mail Brand Settings (system.managemailtemplates) forms include the colorpicker formwidget, however it is also common for theme's to include it on their Theme Customization (cms.managethemeoptions) form. Although this was a 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 and they would then need to convince a user with higher privileges than them to visit an affected Form in the backend. These two factors limit the potential harm of this vulnerability. That being said, all users are advised to update to the latest version (1.2.4) to ensure their systems remain secure. Patches This…
Recommended action: Upgrade to 1.2.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.