Focus on wintercms vulnerabilities and metrics.
Last updated: 29 Jun 2025, 22:25 UTC
This page consolidates all known Common Vulnerabilities and Exposures (CVEs) associated with wintercms. We track both calendar-based metrics (using fixed periods) and rolling metrics (using gliding windows) to give you a comprehensive view of security trends and risk evolution. Use these insights to assess risk and plan your patching strategy.
For a broader perspective on cybersecurity threats, explore the comprehensive list of CVEs by vendor and product. Stay updated on critical vulnerabilities affecting major software and hardware providers.
Total wintercms CVEs: 7
Earliest CVE date: 26 Oct 2022, 15:15 UTC
Latest CVE date: 09 Dec 2024, 21:15 UTC
Latest CVE reference: CVE-2024-54149
30-day Count (Rolling): 0
365-day Count (Rolling): 1
Calendar-based Variation
Calendar-based Variation compares a fixed calendar period (e.g., this month versus the same month last year), while Rolling Growth Rate uses a continuous window (e.g., last 30 days versus the previous 30 days) to capture trends independent of calendar boundaries.
Month Variation (Calendar): 0%
Year Variation (Calendar): -80.0%
Month Growth Rate (30-day Rolling): 0.0%
Year Growth Rate (365-day Rolling): -80.0%
Average CVSS: 0.0
Max CVSS: 0
Critical CVEs (≥9): 0
Range | Count |
---|---|
0.0-3.9 | 7 |
4.0-6.9 | 0 |
7.0-8.9 | 0 |
9.0-10.0 | 0 |
These are the five CVEs with the highest CVSS scores for wintercms, sorted by severity first and recency.
Winter is a free, open-source content management system (CMS) based on the Laravel PHP framework. Winter CMS prior to versions 1.2.7, 1.1.11, and 1.0.476 allow users with access to the CMS templates sections that modify Twig files to bypass the sandbox placed on Twig files and modify resources such as theme customisation values or modify, or remove, templates in the theme even if not provided direct access via the permissions. As all objects passed through to Twig are references to the live objects, it is also possible to also manipulate model data if models are passed directly to Twig, including changing attributes or even removing records entirely. In most cases, this is unwanted behavior and potentially dangerous. To actively exploit this security issue, an attacker would need access to the Backend with a user account with any of the following permissions: `cms.manage_layouts`; `cms.manage_pages`; or `cms.manage_partials`. The Winter CMS maintainers strongly recommend that these permissions only be reserved to trusted administrators and developers in general. The maintainers of Winter CMS have significantly increased the scope of the sandbox, effectively making all models and datasources read-only in Twig, in versions 1.2.7, 1.1.11, and 1.0.476. Thse who cannot upgrade may apply commit fb88e6fabde3b3278ce1844e581c87dcf7daee22 to their Winter CMS installation manually to resolve the issue. In the rare event that a Winter user was relying on being able to write to models/datasources within their Twig templates, they should instead use or create components to make changes to their models.
Server-side Template Injection (SSTI) vulnerability in Winter CMS v.1.2.3 allows a remote attacker to execute arbitrary code via a crafted payload to the CMS Pages field and Plugin components. NOTE: the vendor disputes this because the payload could only be entered by a trusted user, such as the owner of the server that hosts Winter CMS, or a developer working for them.
Winter is a free, open-source content management system. 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. This issue has been patched in v1.2.4.
Winter is a free, open-source content management system. Prior to 1.2.4, 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. This issue has been patched in v1.2.4.
Winter is a free, open-source content management system. Prior to 1.2.4, users with the `media.manage_media` permission can upload files to the Media Manager and rename them after uploading. Previously, media manager files were only sanitized on upload, not on renaming, which could have allowed a stored XSS attack. This issue has been patched in v1.2.4.
Winter is a free, open-source content management system (CMS) based on the Laravel PHP framework. Users with the `backend.manage_branding` permission can upload SVGs as the application logo. Prior to version 1.2.3, SVG uploads were not sanitized, which could have allowed a stored cross-site scripting (XSS) attack. To exploit the vulnerability, an attacker would already need to have developer or super user level permissions in Winter CMS. This means they would already have extensive access and control within the system. Additionally, to execute the XSS, the attacker would need to convince the victim to directly visit the URL of the maliciously uploaded SVG, and the application would have to be using local storage where uploaded files are served under the same domain as the application itself instead of a CDN. This is because all SVGs in Winter CMS are rendered through an `img` tag, which prevents any payloads from being executed directly. These two factors significantly limit the potential harm of this vulnerability. This issue has been patched in v1.2.3 through the inclusion of full support for SVG uploads and automatic sanitization of uploaded SVG files. As a workaround, one may apply the patches manually.
Winter is a free, open-source content management system based on the Laravel PHP framework. The Snowboard framework in versions 1.1.8, 1.1.9, and 1.2.0 is vulnerable to prototype pollution in the main Snowboard class as well as its plugin loader. The 1.0 branch of Winter is not affected, as it does not contain the Snowboard framework. This issue has been patched in v1.1.10 and v1.2.1. As a workaround, one may avoid this issue by following some common security practices for JavaScript, including implementing a content security policy and auditing scripts.