Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
89 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
A security protection device in Session designed to protect session hijacking was not correctly functioning. This function intended to protect user sessions by detecting changes in the User-Agent header, but modifications to this header were not correctly invalidating the user session.
Recommended action: Upgrade to 3.6.3 or 3.5.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Authenticated user with page edit permission can craft HTML, which when rendered in a page history comparison can execute client scripts.
Recommended action: Upgrade to 3.5.4 or 3.4.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 3.5.4 or 3.4.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In follow up to SS-2016-001 there is yet a minor unresolved fix to incorrectly encoded URL.
Recommended action: Upgrade to 3.4.2, 3.3.4, 3.2.6 or 3.1.21 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
silverstripe/framework is vulnerable to XSS in Page name where the payload "<svg/onload=alert(/xss/) will trigger an XSS alert.
Recommended action: Upgrade to 3.5.2 or 3.4.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 3.5.4 or 3.4.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 3.4.1, 3.3.3, 3.2.5 or 3.1.20 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The core template framework/templates/Includes/GridFieldprint.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.
Recommended action: Upgrade to 3.4.1, 3.3.3, 3.2.5 or 3.1.20 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 3.4.1, 3.3.3, 3.2.5 or 3.1.20 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The SSReport, 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.
Recommended action: Upgrade to 3.4.1, 3.3.3, 3.2.5 or 3.1.20 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 3.4.1, 3.3.3, 3.2.5 or 3.1.20 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When a user changes their password, the internal salt used for hashing their password is not updated. Although this is not considered a security vulnerability, this behaviour has been improved to ensure the salt is reset on change of password.
Recommended action: Upgrade to 3.4.1, 3.3.3, 3.2.5 or 3.1.20 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Form fields returning isReadonly() as true are vulnerable to reflected XSS injections. This includes ReadonlyField, LookupField, HTMLReadonlyField, as well as special purpose fields like TimeFieldReadonly. Values submitted to through these form fields are not filtered out from the form session data, and might be shown to the user depending on the form behaviour. For example, form validation errors cause the form to re-render with previously submitted values by default. SilverStripe forms automatically load values from request data (GET and POST), which enables malicious use of URLs if your form uses these fields and doesn't overwrite data on form construction. Readonly and disabled form fields are already filtered out in Form-saveInto(), so maliciously submitted data on these fields doesn't make it into the database unless you are accessing form values directly in your saving logic.
Recommended action: Upgrade to 3.4.2, 3.3.4, 3.2.6 or 3.1.21 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A cross-site scripting vulnerability in VersionedRequestFilter has been found. If an incoming user request should not be able to access the requested stage, an error message is created for display on the CMS login page that they are redirected to. In this error message, the URL of the requested page is interpolated into the error message without being escaped; hence, arbitrary HTML can be injected into the CMS login page.
Recommended action: Upgrade to 3.4.1 or 3.3.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
LoginForm calls disableSecurityToken(), which causes a "shared host domain" vulnerability: http://stackoverflow.com/a/15350123.
Recommended action: Upgrade to 3.3.2, 3.2.4 or 3.1.19 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Default Administrator accounts were not subject to the same brute force protection afforded to other Member accounts. Failed login counts were not logged for default admins resulting in unlimited attempts on the default admin username and password.
Recommended action: Upgrade to 3.3.2, 3.2.4 or 3.1.19 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Due to a lack of parameter sanitisation a carefully crafted URL could be used to inject arbitrary HTML into the CMS Edit page. An attacker could create a URL and share it with a site administrator to perform an attack.
Recommended action: Upgrade to 3.3.2, 3.2.4 or 3.1.19 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 SSTRUSTEDPROXYIPS 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, SSHTTPRequest-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…
Recommended action: Upgrade to 3.3.0, 3.2.2 or 3.1.17 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. The resolution for this issue is to ensure that all gridFieldAlterAction submissions are checked for the SecurityID token during submission.
Recommended action: Upgrade to 3.3.0, 3.2.2 or 3.1.17 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 3.3.0, 3.2.2 or 3.1.17 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
"Add from URL" doesn't clearly sanitise URL server side HtmlEditorFieldToolbar has an action HtmlEditorFieldToolbar#viewfile, which gets called by the CMS when adding a media "from a URL" (i.e. via oembed). This action gets the URL to add in the GET parameter FileURL. However it doesn't do any URL sanitising server side. The current logic will pass this through to Oembed, which will probably reject most dangerous URLs, but it's possible future changes would break this.
Recommended action: Upgrade to 3.2.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A high level XSS risk has been identified in the encoding of validation messages in certain FormField classes. Certain fields such as the NumericField and DropdownField have been identified, but any form field which presents any invalid content as a part of its validation response will be at risk.
Recommended action: Upgrade to 3.2.1 or 3.1.16 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
During installation, certain parameters (adminusername and adminpassword) are not escaped in the setup form. This issue is resolved in 3.1.14 stable, although existing users are advised to remove this file prior to deploying to a production server.
Recommended action: Upgrade to 3.1.14 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When a secure token parameter is provided to a SilverStripe site (such as isDev or flush) an empty token parameter can be provided in order to bypass normal authentication parameters. For instance, http://www.mysite.com/?isDev=1&isDevtoken will force a site to dev mode. Alternatively, "flush" could also be used in succession to cause excessive load on a victim site and risk denial of service. The fix in this case is to ensure that empty tokens fail the validation check.
Recommended action: Upgrade to 3.1.13 or 3.0.14 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A XSS risk exists in the returnURL parameter passed to dev/build. An unvalidated url could cause the user to redirect to an unverified third party url outside of the site. This issue is resolved in framework 3.1.14 stable release.
Recommended action: Upgrade to 3.1.14 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.