ghsa

Some potentially dangerous file types exist in File.allowed_extensions which could allow a malicious CMS user to upload files that then get executed in the security context of the website. We have removed the ability to upload .css, .js, .potm, .dotm, .xltm and .jar files in the default configuration. Since allowed_extensions are synced to webserver configuration (in assets/.htaccess) automatically, this will also deny access to any existing uploads with these extensions. Review our security guidelines for the Common Web Platform and the File Security guide for SilverStripe 4 to find out how to add or remove extensions.

There is a user ID enumeration vulnerability in our brute force error messages. - Users that don't exist in will never get a locked out message - Users that do exist, will get a locked out message This means an attacker can infer or confirm user details that exist in the member table. This issue has been resolved by ensuring that login attempt logging and lockout process works equivalently for non-existent users as it does for existant users. This is a regression of [SS-2017-002](https://www.silverstripe.org/download/security-releases/ss-2017-002).

Under some circumstances a form may populate a PasswordField with submitted data, reflecting submitted data back to a user. The user will only see their own submissions for password data, which is not considered best practice. We are not aware of data leaks to other users, devices or sessions.

A weakness in the .htaccess rules preventing requests to uploaded PHP scripts allows PHP scripts that had made their way into the assets directory to be successfully executed through the use of a specially crafted URL. There are protections in place to disallow upload of PHP scripts through the CMS, meaning this weakness does not lead to direct vulnerabilities. In addition, sites hosted on the New Zealand Common Web Platform or SilverStripe Platform have additional configuration in place which prevents PHP script execution in assets, even in a malicious party manages to upload these into the folder.

There is a vulnerability whereby arbitrary global functions may be executed if malicious user input is passed through to in the second argument of `ViewableData::renderWith`. This argument resolves associative arrays as template placeholders. This exploit requires that user code has been written which makes use of the second argument in `renderWith` and where user input is passed directly as a value in an associative array without sanitisation such as `Convert::raw2xml()`. `ViewableData::customise` is not vulnerable.

A carefully constructed malformed URL can be used to circumvent the offsite redirection protection used on `BackURL` parameters. This could lead to users entering sensitive data in malicious websites instead of the intended one.

When accessing the `install.php` script it is possible to extract any pre-configured database or default admin account password by viewing the source of the page, and inspecting the `value` property of the password fields.

A member with the permission `EDIT_PERMISSIONS` and access to the "Security" section is able to re-assign themselves (or another member) to `ADMIN` level. CMS Fields for the member are constructed using DirectGroups instead of Groups relation which results in bypassing security logic preventing privilege escalation.

The URL parameters `isDev` and `isTest` are accessible to unauthenticated users who access a SilverStripe website or application. This allows unauthorised users to expose information that is usually hidden on production environments such as verbose errors (including backtraces) and other debugging tools only available to sites running in "dev mode". Core functionality does not expose user data through these methods. Depending on your website configuration, community modules might have added more specific functionality which can be used to either access or alter user data. We have fixed the usage of isDev and isTest in SilverStripe 4.x, and removed the URL parameters in the next major release of SilverStripe.

When performing a fulltext search in SilverStripe 4.0.0 the 'start' querystring parameter is never escaped safely. This exposes a possible SQL injection vulnerability. The issue exists in 3.5 and 3.6 but is less vulnerable, as SearchForm sanitises these variables prior to passing to mysql.