Multiple cross-site scripting (XSS) vulnerabilities in SilverStripe before 2.3.5 allow remote attackers to inject arbitrary web script or HTML via (1) the CommenterURL parameter to PostCommentForm, and in the Forum module before 0.2.5 in SilverStripe before 2.3.5 allow remote attackers to inject arbitrary web script or HTML via (2) the Search parameter to forums/search (aka the search script).

Cross-site scripting (XSS) vulnerability in admin/EditForm in SilverStripe 2.4.6 allows remote authenticated users with Content Authors privileges to inject arbitrary web script or HTML via the Title parameter. NOTE: some of these details are obtained from third party information.

Multiple cross-site scripting (XSS) vulnerabilities in the SilverStripe e-commerce module 3.0 for SilverStripe CMS allow remote attackers to inject arbitrary web script or HTML via the (1) FirstName, (2) Surname, or (3) Email parameter to code/forms/OrderFormAddress.php; or the (4) FirstName or (5) Surname parameter to code/forms/ShopAccountForm.php.

security/MemberLoginForm.php in SilverStripe 3.0.3 supports login using a GET request, which makes it easier for remote attackers to conduct phishing attacks without detection by the victim.

security/MemberLoginForm.php in SilverStripe 3.0.3 supports credentials in a GET request, which allows remote or local attackers to obtain sensitive information by reading web-server access logs, web-server Referer logs, or the browser history, a similar vulnerability to CVE-2013-2653.

Open redirect vulnerability in SilverStripe CMS & Framework 3.1.13 allows remote attackers to redirect users to arbitrary web sites and conduct phishing attacks via a URL in the returnURL parameter to dev/build.

Multiple cross-site scripting (XSS) vulnerabilities in SilverStripe CMS & Framework 3.1.13 allow remote attackers to inject arbitrary web script or HTML via the (1) admin_username or (2) admin_password parameter to install.php.

Multiple cross-site scripting (XSS) vulnerabilities in SilverStripe CMS & Framework before 3.1.16 and 3.2.x before 3.2.1 allow remote attackers to inject arbitrary web script or HTML via the (1) Locale or (2) FailedLoginCount parameter to admin/security/EditForm/field/Members/item/new/ItemEditForm.

Response discrepancy in the login and password reset forms in SilverStripe CMS before 3.5.5 and 3.6.x before 3.6.1 allows remote attackers to enumerate users via timing attacks.

SilverStripe CMS before 3.6.1 has XSS via an SVG document that is mishandled by (1) the Insert Media option in the content editor or (2) an admin/assets/add pathname, as demonstrated by the admin/pages/edit/EditorToolbar/MediaForm/field/AssetUploadField/upload URI, aka issue SS-2017-017.

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.

There is XSS in SilverStripe CMS before 3.4.4 and 3.5.x before 3.5.2. The attack vector is a page name. An example payload is a crafted JavaScript event handler within a malformed SVG element.

SQL injection vulnerability in silverstripe/restfulserver module 1.0.x before 1.0.9, 2.0.x before 2.0.4, and 2.1.x before 2.1.2 and silverstripe/registry module 2.1.x before 2.1.1 and 2.2.x before 2.2.1 allows attackers to execute arbitrary SQL commands.

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

In SilverStripe through 4.3.3, a missing warning about leaving install.php in a public webroot can lead to unauthenticated admin access.

SilverStripe through 4.3.3 has Flash Clipboard Reflected XSS.

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 allows a Denial of Service on flush and development URL tools.

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

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

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

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

In the Versioned Files module through 2.0.3 for SilverStripe 3.x, unpublished versions of files are publicly exposed to anyone who can guess their URL. This guess could be highly informed by a basic understanding of the symbiote/silverstripe-versionedfiles source code. (Users who upgrade from SilverStripe 3.x to 4.x and had Versioned Files installed have no further need for this module, because the 4.x release has built-in versioning. However, nothing in the upgrade process automates the destruction of these insecure artefacts, nor alerts the user to the criticality of destruction.)

SilverStripe through 4.4.x before 4.4.5 and 4.5.x before 4.5.2 allows Reflected XSS on the login form and custom forms. Silverstripe Forms allow malicious HTML or JavaScript to be inserted through non-scalar FormField attributes, which allows performing XSS (Cross-Site Scripting) on some forms built with user input (Request data). This can lead to phishing attempts to obtain a user's credentials or other sensitive user input.

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.

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.

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

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 4.5.0 allows attackers to read certain records that should not have been placed into a result set. This affects silverstripe/recipe-cms. The automatic permission-checking mechanism in the silverstripe/graphql module does not provide complete protection against lists that are limited (e.g., through pagination), resulting in records that should have failed a permission check being added to the final result set. GraphQL endpoints are configured by default (e.g., for assets), but the admin/graphql endpoint is access protected by default. This limits the vulnerability to all authenticated users, including those with limited permissions (e.g., where viewing records exposed through admin/graphql requires administrator permissions). However, if custom GraphQL endpoints have been configured for a specific implementation (usually under /graphql), this vulnerability could also be exploited through unauthenticated requests. This vulnerability only applies to reading records; it does not allow unauthorised changing of records.

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.

Silverstripe CMS through 4.5 can be susceptible to script execution from malicious upload contents under allowed file extensions (for example HTML code in a TXT file). When these files are stored as protected or draft files, the MIME detection can cause browsers to execute the file contents. Uploads stored as protected or draft files are allowed by default for authorised users only, but can also be enabled through custom logic as well as modules such as silverstripe/userforms. Sites using the previously optional silverstripe/mimevalidator module can configure MIME whitelists rather than extension whitelists, and hence prevent this issue. Sites on the Common Web Platform (CWP) use this module by default, and are not affected.

In SilverStripe through 4.5, malicious users with a valid Silverstripe CMS login (usually CMS access) can craft profile information which can lead to XSS for other users through specially crafted login form URLs.

Default SilverStripe GraphQL Server (aka silverstripe/graphql) 3.x through 3.4.1 permission checker not inherited by query subclass.

SilverStripe Framework through 4.8.1 allows XSS.

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

Silverstripe silverstripe/framework through 4.10 allows Session Fixation.

Silverstripe silverstripe/framework through 4.10.0 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 sanitise_server_side contig is not set to true in project code.

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

silverstripe-omnipay is a SilverStripe integration with Omnipay PHP payments library. For a subset of Omnipay gateways (those that use intermediary states like `isNotification()` or `isRedirect()`), if the payment identifier or success URL is exposed it is possible for payments to be prematurely marked as completed without payment being taken. This is mitigated by the fact that most payment gateways hide this information from users, however some issuing banks offer flawed 3DSecure implementations that may inadvertently expose this data. The following versions have been patched to fix this issue: `2.5.2`, `3.0.2`, `3.1.4`, and `3.2.1`. There are no known workarounds for this vulnerability.

Silverstripe silverstripe/assets through 1.10 is vulnerable to improper access control that allows protected images to be published by changing an existing image short code on website content.

Silverstripe silverstripe/cms through 4.11.0 allows XSS.

Silverstripe silverstripe/framework through 4.11 allows XSS (issue 1 of 2) via JavaScript payload to the href attribute of a link by splitting a javascript URL with white space characters.

Silverstripe silverstripe/framework through 4.11 allows XSS vulnerability via href attribute of a link (issue 2 of 2).

Silverstripe silverstripe/framework through 4.11 allows XSS (issue 1 of 3) via remote attackers adding a Javascript payload to a page's meta description and get it executed in the versioned history compare view.

Silverstripe silverstripe/framework through 4.11 allows XSS (issue 2 of 3).

Silverstripe silverstripe/framework through 4.11 allows XSS (issue 3 of 3).

Silverstripe silverstripe/framework through 4.11 allows SQL Injection.

Silverstripe silverstripe/framework through 4.11 is vulnerable to XSS by carefully crafting a return URL on a /dev/build or /Security/login request.

Silverstripe silverstripe/framework through 4.11.0, silverstripe/assets through 1.11.0, and silverstripe/asset-admin through 1.11.0 allow XSS.

Silverstripe silverstripe/subsites through 2.6.0 has Insecure Permissions.

Silverstripe Framework is the Model-View-Controller framework that powers the Silverstripe content management system. Prior to version 4.12.15, the GridField print view incorrectly validates the permission of DataObjects potentially allowing a content author to view records they are not authorised to access. Users should upgrade to Silverstripe Framework 4.12.15 or above to address the issue.

Silverstripe Framework is the Model-View-Controller framework that powers the Silverstripe content management system. Prior to version 4.12.15, 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. Users should upgrade to Silverstripe Framework 4.12.15 or above to address the issue.

`silverstripe/graphql` serves Silverstripe data as GraphQL representations. In versions 4.2.2 and 4.1.1, an attacker could use a specially crafted graphql query to execute a denial of service attack against a website which has a publicly exposed graphql endpoint. This mostly affects websites with particularly large/complex graphql schemas. Users should upgrade to `silverstripe/graphql` 4.2.3 or 4.1.2 to remedy the vulnerability.

silverstripe-graphql is a package which serves Silverstripe data in GraphQL representations. An attacker could use a recursive graphql query to execute a Distributed Denial of Service attack (DDOS attack) against a website. This mostly affects websites with publicly exposed graphql schemas. If your Silverstripe CMS project does not expose a public facing graphql schema, a user account is required to trigger the DDOS attack. If your site is hosted behind a content delivery network (CDN), such as Imperva or CloudFlare, this may further mitigate the risk. This issue has been addressed in versions 3.8.2, 4.1.3, 4.2.5, 4.3.4, and 5.0.3. Users are advised to upgrade. There are no known workarounds for this vulnerability.

The Silverstripe CMS GraphQL Server serves Silverstripe data as GraphQL representations. In versions 4.0.0 prior to 4.3.7 and 5.0.0 prior to 5.1.3, `canView` permission checks are bypassed for ORM data in paginated GraphQL query results where the total number of records is greater than the number of records per page. Note that this also affects GraphQL queries which have a limit applied, even if the query isn’t paginated per se. This has been fixed in versions 4.3.7 and 5.1.3 by ensuring no new records are pulled in from the database after performing `canView` permission checks for each page of results. This may result in some pages in the query results having less than the maximum number of records per page even when there are more pages of results. This behavior is consistent with how pagination works in other areas of Silverstripe CMS, such as in `GridField`, and is a result of having to perform permission checks in PHP rather than in the database directly. One may disable these permission checks by disabling the `CanViewPermission` plugin.

Silverstripe Framework is the framework that forms the base of the Silverstripe content management system. Prior to versions 4.13.39 and 5.1.11, 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. Versions 4.13.39 and 5.1.11 contain a fix for this issue.

Silverstripe Admin provides a basic management interface for the Silverstripe Framework. In versions on the 1.x branch prior to 1.13.19 and on the 2.x branch prior to 2.1.8, users who don't have edit or delete permissions for records exposed in a `ModelAdmin` can still edit or delete records using the CSV import form, provided they have create permissions. The likelihood of a user having create permissions but not having edit or delete permissions is low, but it is possible. Note that this doesn't affect any `ModelAdmin` which has had the import form disabled via the `showImportForm` public property. Versions 1.13.19 and 2.1.8 contain a patch for the issue. Those who have a custom implementation of `BulkLoader` should update their implementations to respect permissions when the return value of `getCheckPermissions()` is true. Those who use any `BulkLoader` in their own project logic, or maintain a module which uses it, should consider passing `true` to `setCheckPermissions()` if the data is provided by users.

silverstripe/reports is an API for creating backend reports in the Silverstripe Framework. In affected versions reports can be accessed by their direct URL by any user who has access to view the reports admin section, even if the `canView()` method for that report returns `false`. This issue has been addressed in version 5.2.3. All users are advised to upgrade. There are no known workarounds for this vulnerability.

Silverstripe framework is the PHP framework forming the base for the Silverstripe CMS. In affected versions a bad actor with access to edit content in the CMS could add send a specifically crafted encoded payload to the server, which could be used to inject a JavaScript payload on the front end of the site. The payload would be sanitised on the client-side, but server-side sanitisation doesn't catch it. The server-side sanitisation logic has been updated to sanitise against this type of attack in version 5.2.16. All users are advised to upgrade. There are no known workarounds for this vulnerability.

Silverstripe Framework is a PHP framework which powers the Silverstripe CMS. In some cases, form messages can contain HTML markup. This is an intentional feature, allowing links and other relevant HTML markup for the given message. Some form messages include content that the user can provide. There are scenarios in the CMS where that content doesn't get correctly sanitised prior to being included in the form message, resulting in an XSS vulnerability. This issue has been addressed in silverstripe/framework version 5.3.8 and users are advised to upgrade. There are no known workarounds for this vulnerability.

Silverstripe Framework is a PHP framework which powers the Silverstripe CMS. Prior to 5.3.23, bad actor with access to edit content in the CMS could send a specifically crafted encoded payload to the server, which could be used to inject a JavaScript payload on the front end of the site. The payload would be sanitized on the client-side, but server-side sanitization doesn't catch it. The server-side sanitization logic has been updated to sanitize against this attack. This vulnerability is fixed in 5.3.23.