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
89 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
A vulnerability has been found in the SilverStripe framework where a login url can be potentially redirected to an external site. For example, the url http://www.my-silverstripe-site.com/Security/login?BackURL=/\attacker-site.com will redirect successful logins to the page http://attacker-site.com. If that website were set up to look identical to the first with "login failed" then the user will likely just enter their user/pass again.
Recommended action: Upgrade to 3.1.13 or 3.0.14 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A potential hostname injection vulnerability has been found which could allow attackers to alter url resolution. If a request contains the X-Forwarded-Host HTTP header a website would then use its value in place of the actual HTTP hostname. In cases where caching is enabled, this could allow an attacker to potentially embed a remote url as the baseurl for any site. This would then cause other visitors to the site to be redirected unknowingly. This header is necessary for servers running behind a reverse proxy (such as nginx). Such servers are likely not vulnerable to this risk. A fix has been merged into the default installer, although existing projects which do not run behind a reverse proxy should update their htaccess as below:
Recommended action: Upgrade to 3.1.13 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A low level XSS vulnerability has been found in the Framework affecting http redirection via the Director::forceredirect method. Attempts to redirect to a url may generate HTML which is not safely escaped, and may pose a risk of XSS in some environments. This vulnerability is marked low as it is difficult to exploit, as any injected HTML will only be returned from the server if the Location HTTP header is also sent, meaning that any user browsing the site would not be exposed to the body of the response before their browser redirects them.
Recommended action: Upgrade to 3.1.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A cross-site scripting vulnerability has been discovered in the FormAction field where a user-specified title may be specified.
Recommended action: Upgrade to 3.1.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A high level XSS vulnerability has been discovered in the SilverStripe framework which causes links containing hash anchors (E.g. href="#anchor") to be rewritten in an unsafe way. The rewriteHashlinks option on SSViewer will rewrite these to contain the current url, although without adequate escaping, meaning that HTML could be injected via injecting unsafe values to any page via the querystring. Due to the nature of this issue it is likely that a large number of SilverStripe sites are affected.
Recommended action: Upgrade to 3.1.12 or 3.0.13 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A cross-site scripting vulnerability has been discovered in the print view of GridField. This vulnerability can only be exploited if a user with CMS access has posted malicious or unescaped HTML into any field of an object in a GridField, and the print feature is used. This has been resolved by ensuring that the print feature safely escapes all fields.
Recommended action: Upgrade to 3.1.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A cross-site scripting vulnerability has been discovered in the TreeDropdownField and TreeMultiSelectField. This vulnerability can only be exploited if a user with CMS access has posted malicious or unescaped HTML into any of the dataobjects used as a data source for either of these fields. This has been resolved by ensuring that all dataobjects used as a data source have their content safely encoded.
Recommended action: Upgrade to 3.1.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A low level vulnerability has been found in the SilverStripe framework, where the Quadratic Blowup Attack could potentially be exploited to affect the performance of a site. See http://mashable.com/2014/08/06/wordpress-xml-blowup-dos/ for a writeup.
Recommended action: Upgrade to 3.1.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Non IE browsers don’t appear to be affected, but I haven’t tested a wide range of browsers to be sure Requests that come through from IE do NOT appear to encode all entities in the URL string, meaning they are inserted into output content directly by SSViewer::process() when rewriting hashlinks, as it directly outputs $SERVER[‘REQUESTURI’] Example IE8 request 127.0.0.1 - - [18/Jun/2014:14:13:42 +1000] “GET /site/cars/brands/toyota?one=1\”onmouseover=\”alert(‘things’);\” HTTP/1.1” 200 Example FF request 127.0.0.1 - - [18/Jun/2014:14:14:22 +1000] “GET /site/cars/brands/toyota?one=1\%22onmouseover=\%22alert(%27things%27);\%22 HTTP/1.1” 200 This causes any hash anchor to have the JS code inserted into the page as-is.
Recommended action: Upgrade to 3.1.12 or 3.0.13 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact If a user should not be able to see a record, but that record can be added to a GridField using the GridFieldAddExistingAutocompleter component, the record's title can be accessed by that user. Base CVSS: 4.3 Reported by: Nick K - LittleMonkey, littlemonkey.co.nz References - https://www.silverstripe.org/download/security-releases/CVE-2023-48714
Recommended action: Upgrade to 5.1.11 or 4.13.39 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When a new Member record was created in the cms it was possible to set a blank password. If an attacker knows the email address of the user with the blank password then they can attempt to log in using an empty password. The default member authenticator, login form and basic auth all require a non-empty password, however if a custom authentication method is used it may allow a successful login with the empty password. Starting with this release, blank passwords are no no longer allowed when members are created in the CMS. Programatically created Member records, such as those used in unit tests, still allow blank passwords. You may have some Member records in your system already which have empty passwords. To detect these, you can loop over all Member records with Member::get() and pass each record into the below method. It might be sensible to create a BuildTask for this purpose. Once you have identified the records with empty passwords, it's up to you how to handle this. The most…
Recommended action: Upgrade to 5.0.13 or 4.13.14 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The GridField print view incorrectly validates the permission of DataObjects potentially allowing a content author to view records they are not authorised to access. Upgrade to silverstripe/framework 4.12.5 or above to address the issue. Reported by Stephan Bauer from relaxt Webdienstleistungsagentur GmbH
Recommended action: Upgrade to 4.12.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An attacker can display a link to a third party website on a login screen by convincing a legitimate content author to follow a specially crafted link. Upgrade to silverstripe/framework 4.12.5 or above to remedy the vulnerability. Reporter: Matthew Dekker
Recommended action: Upgrade to 4.12.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Gridfield state is vulnerable to SQL injections. The vast majority of Gridfields in Silverstripe CMS are affected by this vulnerability. An attacker with CMS access could execute an arbitrary SQL statement by adding an SQL payload in some parts of the GridField state.
Recommended action: Upgrade to 4.11.14 or 4.10.11 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An attacker could inject a XSS payload in a Silverstripe CMS response by carefully crafting a return URL on a /dev/build or /Security/login request. To exploit this vulnerability, an attacker would need to convince a user to follow a link with a malicious payload. This will only affect projects configured to output PHP warnings to the browser. By default, Silverstripe CMS will only output PHP warnings if your SSENVIRONMENTTYPE environment variable is set to dev. Production sites should always set SSENVIRONMENTTYPE to live.
Recommended action: Upgrade to 4.11.13 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A malicious content author could add a JavaScript payload to the href attribute of a link by splitting a javascript URL with white space characters. An attacker must have access to the CMS to exploit this issue.
Recommended action: Upgrade to 4.11.13 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A malicious content author could add a Javascript payload to the href attribute of a link. A similar issue was identified and fixed via CVE-2022-28803. However, the fix didn't account for the casing of the href attribute. An attacker must have access to the CMS to exploit this issue.
Recommended action: Upgrade to 4.11.13 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A malicious content author could add arbitrary attributes to HTML editor shortcodes which could be used to inject a JavaScript payload on the front end of the site. The shortcode providers that ship with Silverstripe CMS have been reviewed and attribute whitelists have been implemented where appropriate to negate this risk.
Recommended action: Upgrade to 4.11.13 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Silverstripe silverstripe/framework 4.x until 4.10.9 has a quadratic blowup in Convert::xml2array() that enables a remote attack via a crafted XML document.
Recommended action: Upgrade to 4.10.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
SilverStripe Framework through 4.10.8 allows XSS, inside of script tags that can can be added to website content via XHR by an authenticated CMS user if the cwp-core module is not installed on the sanitiseserverside contig is not set to true in project code.
Recommended action: Upgrade to 4.10.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
SilverStripe Framework 4.x prior to 4.10.9 is vulnerable to cross-site scripting inside the href attribute of an HTML hyperlink, which can be added to website content via XMLHttpRequest (XHR) by an authenticated CMS user.
Recommended action: Upgrade to 4.10.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
SilverStripe through 4.6.0-rc1 has an XXE Vulnerability in CSSContentParser. A developer utility meant for parsing HTML within unit tests can be vulnerable to XML External Entity (XXE) attacks. When this developer utility is misused for purposes involving external or user submitted data in custom project code, it can lead to vulnerabilities such as XSS on HTML output rendered through this custom code. This is now mitigated by disabling external entities during parsing. (The correct CVE ID year is 2020 [CVE-2020-25817, not CVE-2021-25817]).
Recommended action: Upgrade to 4.7.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
SilverStripe through 4.4.4 allows Web Cache Poisoning through HTTPRequestBuilder.
Recommended action: Upgrade to 4.5.4, 4.4.7 or 3.7.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In SilverStripe through 4.5, files uploaded via Forms to folders migrated from Silverstripe CMS 3.x may be put to the default "/Uploads" folder instead. This affects installations which allowed upload folder protection via the optional silverstripe/secureassets module under 3.x. This module is installed and enabled by default on the Common Web Platform (CWP). The vulnerability only affects files uploaded after an upgrade to 4.x.
Recommended action: Upgrade to 4.4.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
SilverStripe before 4.4.0 allows a Denial of Service on flush and development URL tools.
Recommended action: Upgrade to 4.4.0; some affected versions have no fix yet, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.