#vulnerability

Authenticated user with page edit permission can craft HTML, which when rendered in a page history comparison can execute client scripts.

RedirectorPage will allow users to specify a non-url malicious script as the redirection path without validation. Users which follow this url may allow this script to execute within their browser.

In follow up to [SS-2016-001](https://www.silverstripe.org/download/security-releases/ss-2016-001/) there is yet a minor unresolved fix to incorrectly encoded URL.

silverstripe/framework is vulnerable to XSS in Page name where the payload `"><svg/onload=alert(/xss/)>` will trigger an XSS alert.

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.

List of key / value pairs assigned to `OptionsetField` or `CheckboxSetField` do not have a default casting assigned to them. The effect of this is a potential XSS vulnerability in lists where either key or value contain unescaped HTML.

The core template `framework/templates/Includes/GridField_print.ss` uses "Printed by $Member.Name". If the currently logged in members first name or surname contain XSS, this prints the raw HTML out, because Member->getName() just returns the raw FirstName + Surname as a string, which is injected directly.

If remember me is on and users log in with the box checked, if the developer then disabled "remember me" function, any pre-existing cookies will continue to authenticate users.

The SS_Report, and the reports CMS section only checks `canView()` when listing the reports that can be viewed by the current user. It does not (and should) perform `canView` checks when the report is actually viewed, so if you know the URL to a report and can otherwise access the Reports section of the CMS, you can view any report.

After performing a password reset, `ChangePasswordForm::doChangePassword()` logs in the user without checking `Member::canLogIn()`. This presents an issue for sites that are using the extension point in that method to deny access to users (for example members that have not been “approved”, or members that have had their access revoked temporarily). It looks like `Member::canLogIn()` was originally designed to only be used for checking whether the user is locked out (due to too many incorrect login attempts) but has been opened up to other uses.