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.

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

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 headers from connecting clients, this can lead to spoofing requests being passed through trusted proxies. The impact of spoofed headers can include `Director::forceSSL()` not being enforced, SS_HTTPRequest->getIP() returning a wrong IP (disabling any IP restrictions), and spoofed hostnames circumventing any hostname-specific restrictions enforced in SilverStripe Controllers. Regardless on running a reverse proxy in your hosting infrastructure, please follow the instructions on Secure Coding: Request hostname forgery in order to opt-in to these protections. If your website is not behind a reverse proxy, you might already be protected if using Apache with mod_env enabled, and you have the following line in your .htaccess file: `SetEnv BlockUntrustedIPs true`.

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 modified tables, allowing attackers more insight into which modules are used, and how the database tables are structured.

CSRF vulnerability in GridFieldAddExistingAutocompleter
GridField does not have sufficient CSRF protection, meaning that in some cases users with CMS access can be tricked into posting unspecified data into the CMS from external websites. Amongst other default CMS interfaces, GridField is used for management of groups, users and permissions in the CMS.