Silverstripe silverstripe/cms through 4.11.0 allows XSS.

In SilverStripe Framework through 2022-04-07, Stored XSS can occur in javascript link tags added via XMLHttpRequest (XHR).

Silverstripe silverstripe/framework 4.8.1 has a quadratic blowup in Convert::xml2array() that enables a remote attack via a crafted XML document.

SilverStripe Framework through 4.8.1 allows XSS.

In SilverStripe through 4.6.0-rc1, GraphQL doesn't honour MFA (multi-factor authentication) when using basic authentication.

In SilverStripe through 4.6.0-rc1, a FormField with square brackets in the field name skips validation.

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

In SilverStripe through 4.5.0, a specific URL path configured by default through the silverstripe/framework module can be used to disclose the fact that a domain is hosting a Silverstripe application. There is no disclosure of the specific version. The functionality on this URL path is limited to execution in a CLI context, and is not known to present a vulnerability through web-based access. As a side-effect, this preconfigured path also blocks the creation of other resources on this path (e.g. a page).

Silverstripe CMS sites through 4.4.4 which have opted into HTTP Cache Headers on responses served by the framework's HTTP layer can be vulnerable to web cache poisoning. Through modifying the X-Original-Url and X-HTTP-Method-Override headers, responses with malicious HTTP headers can return unexpected responses to other consumers of this cached response. Most other headers associated with web cache poisoning are already disabled through request hostname forgery whitelists.

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.

In SilverStripe through 4.3.3, the previous fix for SS-2018-007 does not completely mitigate the risk of CSRF in GraphQL mutations,

SilverStripe through 4.3.3 allows a Denial of Service on flush and development URL tools.

In SilverStripe assets 4.0, there is broken access control on files.

In SilverStripe asset-admin 4.0, there is XSS in file titles managed through the CMS.

In SilverStripe through 4.3.3, there is access escalation for CMS users with limited access through permission cache pollution.

SilverStripe through 4.3.3 has incorrect access control for protected files uploaded via Upload::loadIntoFile(). An attacker may be able to guess a filename in silverstripe/assets via the AssetControlExtension.

SilverStripe through 4.3.3 has Flash Clipboard Reflected XSS.

SilverStripe through 4.3.3 allows session fixation in the "change password" form.

All versions of SilverStripe 3 prior to 3.6.7 and 3.7.3, and all versions of SilverStripe 4 prior to 4.0.7, 4.1.5, 4.2.4, and 4.3.1 allows Reflected SQL Injection through Form and DataObject.

In the CSV export feature of SilverStripe before 3.5.6, 3.6.x before 3.6.3, and 4.x before 4.0.1, it's possible for the output to contain macros and scripts, which may be executed if imported without sanitization into common software (including Microsoft Excel). For example, the CSV data may contain untrusted user input from the "First Name" field of a user's /myprofile page.