Advisories for Composer/Silverstripe/Cms package

2024

Silverstripe XSS vulnerability via VirtualPage

A cross-site scripting vulnerability has been discovered in the VirtualPage class. This vulnerability can only be exploited if a user with CMS access has posted malicious or unescaped HTML into any of the textfields of a page which a VirtualPage refers to. This has been resolved by ensuring that VirtualPage safely escapes all field content.

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 …

Silverstripe History XSS Vulnerability

A cross-site scripting vulnerability has been discovered in the CMS page history tab. This vulnerability can only be exploited if a user with CMS access has posted malicious or unescaped HTML into any of the text fields on a page, and if the "compare mode" option is selected. The HTML will be embedded into the page unescaped. This has been resolved by performing the text comparison in a HTML friendly …

2022

Stored XSS in custom meta tags

A malicious content author could create a custom meta tag and execute an arbitrary JavaScript payload. This would require convincing a legitimate user to access a page and enter a custom keyboard shortcut. This requires CMS access to exploit.

Unrestricted Upload of File with Dangerous Type

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 …

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 …

Improper Input Validation

code/sitefeatures/PageCommentInterface.php in SilverStripe 2.4.x before 2.4.6 might allow remote attackers to execute arbitrary code via a crafted cookie in a user comment submission, which is not properly handled when it is deserialized.

2019
2016

Missing security check on dev/build/defaults

The buildDefaults method on DevelopmentAdmin is missing a permission check. In live mode, if you access /dev/build, you are requested to login first. However, if you access /dev/build/defaults, then the action is performed without any login check. This should be protected in the same way that /dev/build is. The buildDefaults view is requireDefaultRecords() on each DataObject class, and hence has the potential to modify database state. It also lists all …

Hostname, IP and Protocol Spoofing through HTTP Headers

In it's default configuration, SilverStripe trusts all originating IPs to include HTTP headers for Hostname, IP and Protocol. This enables reverse proxies to forward requests while still retaining the original request information. Trusted IPs can be limited via the SS_TRUSTED_PROXY_IPS constant. Even with this restriction in place, SilverStripe trusts a variety of HTTP headers due to different proxy notations (e.g. X-Forwarded-For vs. Client-IP). Unless a proxy explicitly unsets invalid HTTP …

2015

Queued jobs serialised data exposure

SavedJobData and SavedJobMessages contain php serialized data. There's no point showing these to a CMS Admin as they're not human readable. Worse, it might be insecure, as a malicious CMS Admin might be able to craft a payload thats dangerous to unserialize. This issue has been resolved by hiding this content, even from administrators.

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 …