Package Instance

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.

Unrestricted Upload of File with Dangerous Type
Silverstripe CMS 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.

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

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.

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

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.

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.

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.

Cross-site Scripting
In SilverStripe, 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 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.

Information Exposure
In SilverStripe, 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).

Improper Privilege Management
In SilverStripe, a missing warning about leaving `install.php` in a public webroot can lead to unauthenticated admin access.