Package Instance

Silverstripe CMS XSS Vulnerability
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.

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

Cross-site Scripting
SilverStripe CMS has an 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.

Silverstripe CMS malicious file upload enables script execution
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.

Silverstripe CMS information disclosure
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).

Cross-site Scripting
There is an XSS in SilverStripe CMS.

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
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.

Information Exposure
Response discrepancy in the login and password reset forms in SilverStripe CMS allows remote attackers to enumerate users via timing attack.

Silverstripe CMS Open Redirect
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.

Incorrect Permission Assignment for Critical Resource
SiteTree Creation Permission Vulnerability in silverstripe.

Silverstripe SiteTree Creation Permission Vulnerability
A vulnerability exists in the permission validation for SiteTree object creation. By default user permissions are not validated by the SiteTree::canCreate method, unless overridden by user code or via the configuration system.

This vulnerability will allow users, or unauthenticated guests, to create new SiteTree objects in the database. This vulnerability is present when such users are given CMS access via other means, or if there is another mechanism (such as RestfulServer module) which allows model editing and relies on model-level permission checks.

This vulnerability is restricted to the creation of draft or live pages, and does not allow users to edit, publish, or unpublish existing pages.

All users should upgrade as soon as possible.

Advanced workflow member field exposure
By default, the CMS Admin editable template for the NotifyUsers action has access to a large number of fields, including (for instance) `Member#Password`. This would allow a malicious CMS Admin to extract other admin passwords by adding a template emailing these fields to themselves when other admins trigger the workflow. A new configuration option has been added; when this option is set to `true` via the Config API then only member fields specified via `Member.summary_fields` may be accessed.