Advisories for Composer/Silverstripe/Framework package

If a website has been set to the "dev" environment mode, a URL can be provided which includes an XSS payload which will be executed in the resulting error message.

When using the "insert media" functionality, the linked oEmbed JSON includes an HTML attribute which will replace the embed shortcode. The HTML is not sanitized before replacing the shortcode, allowing a script payload to be executed on both the CMS and the front-end of the website.

In some cases, form messages can contain HTML markup. This is an intentional feature, allowing links and other relevant HTML markup for the given message. Some form messages include content that the user can provide. There are scenarios in the CMS where that content doesn't get correctly sanitised prior to being included in the form message, resulting in an XSS vulnerability.

[!IMPORTANT] This vulnerability only affects sites which are in the "dev" environment mode. If your production website is in "dev" mode, it has been misconfigured, and you should immediately swap it to "live" mode. See https://docs.silverstripe.org/en/developer_guides/debugging/environment_types/ for more information. If a website has been set to the "dev" environment mode, a URL can be provided which includes an XSS payload which will be executed in the resulting error message.

TinyMCE v6 has a configuration value convert_unsafe_embeds set to false which allows svg files containing javascript to be used in <object> or <embed> tags, which can be used as a vector for XSS attacks. Note that <embed> tags are not allowed by default. After patching the default value of convert_unsafe_embeds will be set to true. This means that <object> tags will be converted to iframes instead the next time the …

A bad actor with access to edit content in the CMS could send a specifically crafted encoded payload to the server, which could be used to inject a JavaScript payload on the front end of the site. The payload would be sanitised on the client-side, but server-side sanitisation doesn't catch it. The server-side sanitisation logic has been updated to sanitise against this type of attack.

When running SilverStripe 3.7 or 4.x in dev mode with the mysqli database driver, there is a potential to disclose the connection details. We have denylisted the sensitive parts of the connection information from being included in dev mode stack traces when database errors occur.

A potential SQL injection vulnerability was identified by using the silverstripe/postgresql database adapter. While unlikely to be exploitable, we have patched silverstripe/framework to ensure that table names are safely escaped before being passed to database adapters or user code.

A possible denial of service attack vector has been identified in the dev/build system controller. dev/build now has its own URL token, similar to flushtoken, to ensure users are authenticated when running dev/build outside of dev environments.

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.

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 …

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.

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.

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.

User enumeration is possible by performing a timing attack on the login or password reset pages with user credentials.

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 …

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.

All user login attempts are logged in the database in the LoginAttempt table. However, this table contains information in plain text, and may possible contain sensitive information, such as user passwords mis-typed into the username field. In order to address this a one-way hash is applied to the Email field before being stored.

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 …

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.

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

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.

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.

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 …

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.

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

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

In follow up to SS-2016-001 there is yet a minor unresolved fix to incorrectly encoded URL.

In the CSV export feature of the CMS it's possible for the output to contain macros and scripts, which if imported without sanitisation into software (including Microsoft Excel) may be executed. In order to safeguard against this threat all potentially executable cell values exported from CSV will be prepended with a literal tab character.

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(). …

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 …

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.

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

Form fields returning isReadonly() as true are vulnerable to reflected XSS injections. This includes ReadonlyField, LookupField, HTMLReadonlyField, as well as special purpose fields like TimeField_Readonly. 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 …

A cross-site scripting vulnerability has been discovered in the TreeDropdownField and TreeMultiSelectField. This vulnerability can only be exploited if a user with CMS access has posted malicious or unescaped HTML into any of the dataobjects used as a data source for either of these fields. This has been resolved by ensuring that all dataobjects used as a data source have their content safely encoded.

A high level XSS vulnerability has been discovered in the SilverStripe framework which causes links containing hash anchors (E.g. href="#anchor") to be rewritten in an unsafe way. The rewriteHashlinks option on SSViewer will rewrite these to contain the current url, although without adequate escaping, meaning that HTML could be injected via injecting unsafe values to any page via the querystring. Due to the nature of this issue it is likely …

A cross-site scripting vulnerability has been discovered in the print view of GridField. This vulnerability can only be exploited if a user with CMS access has posted malicious or unescaped HTML into any field of an object in a GridField, and the print feature is used. This has been resolved by ensuring that the print feature safely escapes all fields.

A cross-site scripting vulnerability has been discovered in the FormAction field where a user-specified title may be specified.

A low level XSS vulnerability has been found in the Framework affecting http redirection via the Director::force_redirect method. Attempts to redirect to a url may generate HTML which is not safely escaped, and may pose a risk of XSS in some environments. This vulnerability is marked low as it is difficult to exploit, as any injected HTML will only be returned from the server if the Location HTTP header is …

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.

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.

A potential hostname injection vulnerability has been found which could allow attackers to alter url resolution. If a request contains the X-Forwarded-Host HTTP header a website would then use its value in place of the actual HTTP hostname. In cases where caching is enabled, this could allow an attacker to potentially embed a remote url as the base_url for any site. This would then cause other visitors to the site …

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 …

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 …

LoginForm calls disableSecurityToken(), which causes a "shared host domain" vulnerability: http://stackoverflow.com/a/15350123.

Non IE browsers don’t appear to be affected, but I haven’t tested a wide range of browsers to be sure Requests that come through from IE do NOT appear to encode all entities in the URL string, meaning they are inserted into output content directly by SSViewer::process() when rewriting hashlinks, as it directly outputs $_SERVER[‘REQUEST_URI’] Example IE8 request 127.0.0.1 - - [18/Jun/2014:14:13:42 +1000] “GET /site/cars/brands/toyota?one=1\”onmouseover=\”alert(‘things’);\” HTTP/1.1” 200 Example FF request …

"Add from URL" doesn't clearly sanitise URL server side HtmlEditorField_Toolbar has an action HtmlEditorField_Toolbar#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 …

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 …

A low level vulnerability has been found in the SilverStripe framework, where the Quadratic Blowup Attack could potentially be exploited to affect the performance of a site. See http://mashable.com/2014/08/06/wordpress-xml-blowup-dos/ for a writeup.

During installation, certain parameters (admin_username and admin_password) 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.

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.

A vulnerability has been found in the SilverStripe framework where a login url can be potentially redirected to an external site. For example, the url http://www.my-silverstripe-site.com/Security/login?BackURL=/\attacker-site.com will redirect successful logins to the page http://attacker-site.com. If that website were set up to look identical to the first with "login failed" then the user will likely just enter their user/pass again.

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.

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.

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.

Silverstripe Framework is the framework that forms the base of the Silverstripe content management system. Prior to versions 4.13.39 and 5.1.11, if a user should not be able to see a record, but that record can be added to a GridField using the GridFieldAddExistingAutocompleter component, the record's title can be accessed by that user. Versions 4.13.39 and 5.1.11 contain a fix for this issue.

Silverstripe Framework is the MVC framework that powers Silverstripe CMS. When a new member record is created and a password is not set, an empty encrypted password is generated. As a result, if someone is aware of the existence of a member record associated with a specific email address, they can potentially attempt to log in using that empty password. Although the default member authenticator and login form require a …

Silverstripe Framework is the Model-View-Controller framework that powers the Silverstripe content management system. Prior to version 4.12.15, an attacker can display a link to a third party website on a login screen by convincing a legitimate content author to follow a specially crafted link. Users should upgrade to Silverstripe Framework 4.12.15 or above to address the issue.

Silverstripe Framework is the Model-View-Controller framework that powers the Silverstripe content management system. Prior to version 4.12.15, the GridField print view incorrectly validates the permission of DataObjects potentially allowing a content author to view records they are not authorised to access. Users should upgrade to Silverstripe Framework 4.12.15 or above to address the issue.

Silverstripe silverstripe/cms through 4.11.0 allows XSS.

Silverstripe silverstripe/framework through 4.11 allows SQL Injection.

A malicious content author could add arbitrary attributes to HTML editor shortcodes which could be used to inject a JavaScript payload on the front end of the site. The shortcode providers that ship with Silverstripe CMS have been reviewed and attribute allow lists have been implemented where appropriate to negate this risk.

A malicious content author could add a Javascript payload to the href attribute of a link. A similar issue was identified and fixed via CVE-2022-28803. However, the fix didn't account for the casing of the href attribute. An attacker must have access to the CMS to exploit this issue.

A malicious content author could add a JavaScript payload to the href attribute of a link by splitting a javascript URL with white space characters. An attacker must have access to the CMS to exploit this issue.

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') in silverstripe/framework.

In SilverStripe Framework, Stored XSS can occur in javascript link tags added via XMLHttpRequest (XHR).

Silverstripe silverstripe/framework through 4.10.0 allows XSS, inside of script tags that can can be added to website content via XHR by an authenticated CMS user if the cwp-core module is not installed on the sanitise_server_side contig is not set to true in project code.

Silverstripe silverstripe/framework has a quadratic blowup in Convert::xml2array() that enables a remote attack via a crafted XML document.

SilverStripe through 4.4.4 allows Web Cache Poisoning through HTTPRequestBuilder.

Multiple cross-site scripting (XSS) vulnerabilities in SilverStripe 2.3.x before 2.3.13 and 2.4.x before 2.4.7 allow remote attackers to inject arbitrary web script or HTML via (1) a crafted string to the AbsoluteLinks, (2) BigSummary, (3) ContextSummary, (4) EscapeXML, (5) FirstParagraph, (6) FirstSentence, (7) Initial, (8) LimitCharacters, (9) LimitSentences, (10) LimitWordCount, (11) LimitWordCountXML, (12) Lower, (13) LowerCase, (14) NoHTML, (15) Summary, (16) Upper, (17) UpperCase, or (18) URL method in a …

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.

Business Logic Errors in GitHub repository silverstripe/silverstripe-framework

Default SilverStripe GraphQL Server (aka silverstripe/graphql) permission checker is not inherited by query subclass.

SilverStripe Framework allows XSS.

SilverStripe has an XXE Vulnerability in CSSContentParser. A developer utility meant for parsing HTML within unit tests can be vulnerable to XML External Entity (XXE) attacks. When this developer utility is misused for purposes involving external or user submitted data in custom project code, it can lead to vulnerabilities such as XSS on HTML output rendered through this custom code. This is now mitigated by disabling external entities during parsing.

In SilverStripe, a FormField with square brackets in the field name skips validation.

In SilverStripe, GraphQL does not honour MFA (multi-factor authentication) when using basic authentication.

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 …

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.

In SilverStripe, files uploaded via Forms to folders migrated from Silverstripe may be put to the default /Uploads folder instead.

SilverStripe allows a Denial of Service on flush and development URL tools.

SilverStripe is vulnerable to CSRF in GraphQL mutations

SilverStripe allows Reflected XSS on the login form and custom forms. Silverstripe Forms allow malicious HTML or JavaScript to be inserted through non-scalar FormField attributes, which allows performing XSS (Cross-Site Scripting) on some forms built with user input (Request data). This can lead to phishing attempts to obtain a user's credentials or other sensitive user input.

In the Versioned Files module through 2.0.3 for SilverStripe 3.x, unpublished versions of files are publicly exposed to anyone who can guess their URL. This guess could be highly informed by a basic understanding of the symbiote/silverstripe-versionedfiles source code. (Users who upgrade from SilverStripe 3.x to 4.x and had Versioned Files installed have no further need for this module, because the 4.x release has built-in versioning. However, nothing in the …

In SilverStripe, there is access escalation for CMS users with limited access through permission cache pollution.

In SilverStripe, there is broken access control on files.

In SilverStripe asset-admin, there is XSS in file titles managed through the CMS.

SilverStripe allows session fixation in the "change password" form.

SilverStripe has incorrect access control for protected files uploaded via Upload::loadIntoFile(). An attacker may be able to guess a filename in silverstripe/assets via the AssetControlExtension.

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

SilverStripe has Flash Clipboard Reflected XSS.

SilverStripe allowss Reflected SQL Injection through Form and DataObject.

In the CSV export feature of SilverStripe, it is possible for the output to contain macros and scripts, which may be executed if imported without sanitization into common software.

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

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.

There is an XSS in SilverStripe CMS.

SilverStripe is vulnerable to XSS via the page name. For instance, page name "><svg/onload=alert(/xss/)> will trigger an XSS alert.

In follow up to SS-2016-001 there is yet a minor unresolved fix to incorrectly encoded URL.

Form fields returning isReadonly() as true are vulnerable to reflected XSS injections. This includes ReadonlyField, LookupField, HTMLReadonlyField, as well as special purpose fields like TimeField_Readonly. 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 …

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.

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.

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.

When a user changes their password, the internal salt used for hashing their password is not updated.

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.

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.

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 …

A XSS risk exists in the returnURL parameter passed to CMSSecurity/success. An unvalidated url could cause the user to redirect to an unverified third party url outside of the site.

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.

LoginForm calls disableSecurityToken(), which causes a "shared host domain" vulnerability.

savetreenode action 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.

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.

SS-2016-003: Hostname, IP and Protocol Spoofing through HTTP Headers

'Missing security check on dev/build/defaults.

CSRF vulnerability in GridFieldAddExistingAutocompleter.

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.

"Add from URL" does not clearly sanitize URL server side in HtmlEditorField_Toolbar. 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.

HtmlEditor improper URL sanitisation.

Form field validation message XSS vulnerability.

A member with the permission EDIT_PERMISSIONS is able to re-assign themselves (or another member) to ADMIN level.

XSS in dev/build returnURL Parameter.

XSS in install.php.

X-Forwarded-Host request hostname injection.

Vulnerability on isDev, isTest and flush $_GET validation.

External redirection risk in Security?ReturnURL.

Potential SQL Injection Vulnerability in silverstripe.

IE requests not properly behaving with rewritehashlinks.

XSS In rewritten hash links.

XSS in Director::force_redirect().

XSS In FormAction.

XSS In GridField print.

TreeDropdownField and TreeMultiSelectField XSS.

XML Quadratic Blowup vulnerability.