Security Releases

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

When potential security holes are discovered in SilverStripe's supported modules, we produce security releases to ensure that you are able to promptly secure your SilverStripe websites (check our security release process). All releases are available on our download page, and are announced on our forums (register to subscribe). Vulnerabilities in releases are disclosed here. Please subscribe to our security release RSS feed and pre-announcement mailing list to stay updated.

CVE-2021-28661 Default GraphQL permission checker not inherited by query subclass

Severity:

Low (?)

Identifier:
CVE-2021-28661

Versions Affected:
silverstripe/graphql: ^3.0.0

Versions Fixed:
silverstripe/graphql: ^3.5.2, silverstripe/graphql: ^3.6.0

Release Date:
2021-10-05

CMS users without limited permissions to view data may be able access privileged information via the /admin/graphql endpoint because of a missing canView() on data. This affects data classes that utilise or inherit from the Read or ReadOne GraphQL 3 classes that don't explicitly assign a service class to the permissionChecker property of their implementation. On a default installation this will expose limited (ID, FirstName, Surname) information from the Member table which a CMS user typically will not have access to.
Graphql 4 is not affected by this.
If you have a legitimate use for an ItemQuery/ListQuery scaffolder class without a permission checker, you can use the following example.
```
# Put this in `app/_config/mysite.yml` on another config file
SilverStripe\Core\Injector\Injector:
  My\App\QueryPermissionChecker.nocheck:
    class: My\App\NoCheckPermissionChecker
  My\App\CustomItemQueryScaffolder:
    properties:
      permissionChecker: '%$My\App\QueryPermissionChecker.nocheck'
  My\App\CustomListQueryScaffolder:
    properties:
      permissionChecker: '%$My\App\QueryPermissionChecker.nocheck'
```
```
<?php

namespace My\App;

use SilverStripe\GraphQL\Permission\QueryPermissionChecker;
use SilverStripe\ORM\Filterable;
use SilverStripe\Security\Member;

class NoCheckPermissionChecker implements QueryPermissionChecker
{
    public function applyToList(Filterable $list, Member $member = null)
    {
        return $list;
    }

    public function checkItem($item, Member $member = null)
    {
        return true;
    }
}
```
Base CVSS: 3.0
CWP CVSS: 3.0
Reporters:
- ZX Security Ltd
- Luke Edwards from DNA Design (lukereative on GitHub)
CVE-2021-25817 XXE Vulnerability in CSSContentParser

Severity:

Low (?)

Identifier:
CVE-2021-25817

Versions Affected:
silverstripe/framework: ^4.0.0

Versions Fixed:
silverstripe/framework: ^4.7.4, ^4.8.0

Release Date:
2021-06-08

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.
Base CVSS: 3.3
CWP CVSS: 3.3
Thanks to Wang Zhen and Christopher Darling for reporting.
CVE-2020-26138 FormField with square brackets in field name skips validation

Severity:

Low (?)

Identifier:
CVE-2020-26138

Versions Affected:
silverstripe/framework: ^3.0.0, ^4.0.0

Versions Fixed:
silverstripe/framework: ^4.7.4, ^4.8.0

Release Date:
2021-06-08

FileField with array notation skips validation
The FileField class is commonly used for file upload in custom code on a Silverstripe website. This field is designed to be used with a single file upload.
PHP allows for submitting multiple values by adding square brackets to the field name. When this is done to a FileField, it will be coerced into allowing multiple files by using this notation. This is not a supported feature, though nothing is done to prevent this.
In this scenario, validation such as limiting allowed extensions is not applied, and the FileField->saveInto() behaviour is not triggered. If custom controller logic is used to process the file uploads, it might implicitly rely on validation to be provided by the Form system, which is not the case.
Note this issue is for the FileField, not the UploadField which is used within the CMS.
Example:
```
public function MyForm()
{
  $fields = FieldList::create(
    FileField::create('MySafeField')->setAllowedExtensions(['pdf']),
    FileField::create('MyUnsafeField[]')->setAllowedExtensions(['pdf'])
  );
  $actions = FieldList::create(
    FormAction::create('submit')
  );
  $validator = RequiredFields::create('MySafeField', 'MyUnsafeField');
  return Form::create($this, 'Form', $fields, $actions, $validator);
}

public function submit($data, $form)
{
  $data['MyUnsafeField'] // not validated
  $_FILES['MyUnsafeField'] // not validated
}
```
Base CVSS: 3.4
CWP CVSS: 3.4
Reporters: Dylan Wagstaff from Silverstripe Ltd
CVE-2020-26136 GraphQL doesn't honour MFA when using basic auth

Severity:

Medium (?)

Identifier:
CVE-2020-26136

Versions Affected:
silverstripe/graphql: ^3.0.0, ^4.0.0-alpha1

Versions Fixed:
silverstripe/graphql: ^3.5.0, ^4.0.0-alpha2

Release Date:
2021-06-08

The GraphQL module accepts basic-auth as an authentication method by default. This can be used to bypass MFA authentication if the silverstripe/mfa module is installed, which is now a commonly installed module. A users password is still required though.
Basic-auth has been removed as a default authentication method. It desired, it can be re-enabled by adding it to the authenticators key of a schema, or on SilverStripe\Graphql\Auth\Handler, i.e.
```
  authenticators:
    -
      class: SilverStripe\GraphQL\Auth\BasicAuthAuthenticator
      priority: 20
```
Base CVSS: 4.2
CWP CVSS: 4.2
Reporters: Maxime Rainville from Silverstripe Ltd
CVE-2021-27938 XSS in CreateQueuedJobTask

Severity:

High (?)

Identifier:
CVE-2021-27938

Versions Affected:
symbiote/silverstripe-queuedjobs: ^3.0.0, ^4.0.0

Versions Fixed:
symbiote/silverstripe-queuedjobs: 3.0.2, 3.1.4, 4.0.7, 4.1.2, 4.2.4, 4.3.3, 4.4.3, 4.5.1, 4.6.4

Release Date:
2021-03-15

A high severity security vulnerability has been identified in the Silverstripe CMS 3 and 4 version of the symbiote/silverstripe-queuedjobs module, which is a popular optional module used to manage dev tasks in the CMS UI for the Silverstripe CMS. A Cross Site Scripting vulnerability allows an attacker to inject an arbitrary payload in the CreateQueuedJobTask dev task via a specially crafted URL.

The corresponding releases contains a fix. We recommend reviewing the impact it may have on your site(s) and upgrading as soon as possible.
Base CVSS: 7.1
CWP CVSS: 7.1
Reporters: Michael Tsai from ZX Security
CVE-2020-9311 Malicious user profile information can cause login form XSS

Severity:

Medium (?)

Identifier:
CVE-2020-9311

Versions Affected:
silverstripe/framework: ^3.0

Versions Fixed:
silverstripe/framework: 3.7.5

Release Date:
2020-07-13

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.
Base CVSS: 4.6
CWP CVSS: 4.6
Reporter: Devi Prasad, Application Security, Ceva Logistics
CVE-2020-9309 Script execution on protected files with MIME spoofing content

Severity:

Medium (?)

Identifier:
CVE-2020-9309

Versions Affected:
silverstripe/recipe-core: ^4.0.0

Versions Fixed:
silverstripe/recipe-core: 4.6.0 or silverstripe/mimetype-validator: 2.0.0

Release Date:
2020-07-13

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. Uploads stored as protected or draft files are allowed by default for authorised users only, but can also be enabled through custom logic as well as modules such as silverstripe/userforms.
Sites using the previously optional silverstripe/mimevalidator module can configure MIME whitelists rather than extension whitelists, and hence prevent this issue. Sites on the Common Web Platform (CWP) use this module by default, and are not affected.
Sites upgrading to silverstripe/recipe-core 4.6.0 will automatically be protected, as silverstripe/mimevalidator is now a core dependency. Sites using an older version of silverstripe/recipe-core need to manually install and configure silverstripe/mimevalidator.
Read the changelog for your targeted release for more information on the best course of action:
Base CVSS: 4.6
CWP CVSS: 0.0 (CWP customers are unaffected by this vulnerability.)
Reporter: Maxime Rainville, Senior Open-Source Developer, Silverstripe Ltd
Addendum: silverstripe/userforms 5.6.0 added an explicit requirement on silverstripe/mimevalidator for the file upload field as a further security enhancement. However, this fix was not properly merged up in the development branches, so silverstripe/userforms 5.6.1. 5.6.2 and 5.7.0 erroneously removed the new mimevalidator package. silverstripe/userforms 5.6.3 and 5.7.1 have been tagged to reintroduce the mimevalidator package and remedy this issue.
CVE-2020-6165 Limited queries break CanViewPermissionChecker

Severity:

Medium (?)

Identifier:
CVE-2020-6165

Versions Affected:
silverstripe/graphql: ^3.2, silverstripe/recipe-cms: ^4.5.0

Versions Fixed:
silverstripe/graphql: 3.2.4, silverstripe/graphql: 3.3.0

Release Date:
2020-07-13

The automatic permission checking mechanism in the silverstripe/graphql module does not provide complete protection against lists that are limited (e.g. through pagination), resulting in records that should fail the permission check being added to the final result set.
GraphQL endpoints are configured by default through the CMS (e.g. for assets), but the admin/graphql endpoint is access protected by default. This limits the vulnerability to users with access to the CMS, but still applies when those authenticated users have limited permissions (e.g. where viewing records exposed through admin/graphql require administrator permissions).
Where custom GraphQL endpoints have been be configured for a specific implementation (usually under /graphql), this vulnerability could also be exploited through unauthenticated requests.
This vulnerability only applies for reading records it does not allow unauthorised changing of records.
If your project implements custom GraphQL queries returning a query-limited result set, you might have to validate that those queries still work as expected and adjust them if they don't.

Review the 4.5.3 changelogs or the 4.6.0 changelogs for additional details on how to upgrade your project.
Base CVSS Score: 5.3
CWP CVSS Score: 5.3
Reporter: Matthias Leutenegger, CEO, Syntro GmbH and Rob Ingram
CVE-2020-6164 Information disclosure on /interactive URL path

Severity:

Low (?)

Identifier:
CVE-2020-6164

Versions Affected:
silverstripe/framework: ^3.0, silverstripe/framework: ^4.0

Versions Fixed:
silverstripe/framework: 4.4.7, silverstripe/framework: 4.5.4, silverstripe/framework: 4.6.0

Release Date:
2020-07-13

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).
Base CVSS: 0.0
CWP CVSS: 0.0
Reporter: Elliot Sawyer, Senior Silverstripe Developer, Catalyst
CVE-2019-19326 Web Cache Poisoning through HTTPRequestBuilder

Severity:

Medium (?)

Identifier:
CVE-2019-19326

Versions Affected:
silverstripe/framework: ^3.0, silverstripe/framework: ^4.0

Versions Fixed:
silverstripe/framework: 3.7.5, silverstripe/framework: 4.4.7, silverstripe/framework: 4.5.4, silverstripe/framework: 4.6.0

Release Date:
2020-07-13

Silverstripe CMS sites which have opted into HTTP Cache Headers on responses served by the framework's HTTP layer can be vulnerable to web cache poisoning. Through modifying the X-Original-Url and X-HTTP-Method-Override headers, responses with malicious HTTP headers can return unexpected responses to other consumers of this cached response. Most other headers associated with web cache poisoning are already disabled through request hostname forgery whitelists.
Silverstripe CMS also supports an alternative means to override a request's HTTP method by including a _method parameter in a POST request. This behaves similarly to the X-HTTP-Method-Override headers and is susceptible to the same vulnerability.
The impact of this vulnerability depends on how you are using request data. The risk potential increases when your site allows user contributed content (such as comments or wiki-style pages).
In addition to public cache headers such as Cache-Control: max-age=<age>, there needs to be an intermediary HTTP cache between the website user and the server. This role is often filled by Content Delivery Networks (CDNs) and system components such as Varnish, but can also appear in the user's own network path (corporate proxies). See PortSwigger: Web Cache Poisoning for more details on the concept.
If your Silverstripe CMS site requires those headers the work, you may need to take additional step when upgrading. Review the changelog for the version you plan to upgrade to:
Base CVSS: 5.9
CWP CVSS: 5.9
Reporters:
- memN0ps
- Will Boucher, Pulse Security
- Sabine Degen
CVE-2020-9280 Folders migrated from 3.x may be unsafe to upload to

Severity:

Medium (?)

Identifier:
CVE-2020-9280

Versions Affected:
silverstripe/assets:^1.0

Versions Fixed:
silverstripe/assets:1.4.7, silverstripe/assets:1.5.2, silverstripe/framework:4.4.6, silverstripe/assets:4.5.3, silverstripe/userforms:5.4.2, silverstripe/assets:5.5.2

Release Date:
2020-04-14

Files uploaded via Forms to folders migrated from Silverstripe CMS 3.x may be put to the default "/Uploads" folder instead. Uploads performed via the CMS UI are not affected.
This is a security issue because the default "/Uploads" folder is publicly accessible by default, which means unauthorised parties may access the uploaded files via HTTP by guessing the file name.
This affects installations which allowed upload folder protection via the optional silverstripe/secureassets module under 3.x. This module is installed and enabled by default on the Common Web Platform (CWP). The vulnerability only affects files uploaded after an upgrade to 4.x. It does not affect files uploaded before the upgrade. Without this module, the issue manifests as duplicated folders and wrong usage of the default assets/Uploads folder. In case protections are applied in other ways (e.g. htaccess or proxy rules), this might also lead to the same security issue.
The most common way to generate file uploads outside of the CMS is the silverstripe/userforms module, but this issue has also been confirmed on custom form implementations.
Files in unprotected folders can be surfaced through custom implementations (such as indexing file content through website search). They can also be surfaced by malicious parties gaining access to the direct download link. Since Silverstripe does not allow listing of files to unauthorised users by default, this usually involves guessing file names. How predictable these file names are depends on your user submissions and your particular use case.
To check if you are affected, review all userforms on your website, and check the "upload folder" setting in any "file field" instances. In the "Assets" section, you can check if this folder has protections applied to it. Follow the same process for any custom form implementations in your project.
Read the Silverstripe CMS 4.4.6 changelogs for detailed steps on applying the patch and running related migration tasks.
Base CVSS: 5.9
CWP CVSS: 5.9
Reporter: Ingo Schommer, Lead Product Architect, Silverstripe Ltd.
CVE-2019-19325 XSS through non-scalar FormField attributes

Severity:

High (?)

Identifier:
CVE-2019-19325

Versions Affected:
silverstripe/framework:^4.3.0

Versions Fixed:
silverstripe/framework:4.4.5, silverstripe/framework:4.5.2

Release Date:
2020-02-17

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. There is no known attack vector for extracting user-session information or credentials automatically, it required a user to fall for the phishing attempt. XSS can also be used to modify the presentation of content in malicious ways.
The vulnerability is known to apply in at least the following cases:
- The login form provided by Silverstripe. When the login form is used with Multi Factor Authentication (MFA), the attack complexity for phishing increases, and is mitigated by using security keys such as Yubikey as an unphishable token.
- Forms which are configured to populate field values based on request parameters. This usually happens via setting the $value on a FormField instance during construction of the form, or by loading request data via Form->loadDataFrom($myRequest->getVars()).
- Forms which have form validation applied through RequiredFields, and opt-out of using CSRF tokens via disableSecurityToken(). In this case, the vulnerability is more impactful if the form is also configured to accept GET submissions, rather than the default of POST submissions.
The vulnerability has not identified on forms created through the silverstripe/userforms module.
Base CVSS: 7.5
CWP CVSS: 0.0
Reported by: Ed Chipman, Senior Solutions Architect, Webbuilders Group
CVE-2019-16409 secureassets and versionedfiles modules can expose versions of protected files

Severity:

Medium (?)

Identifier:
CVE-2019-16409

Versions Affected:
^4.0

Versions Fixed:
4.3.5, 4.4.4

Release Date:
2019-09-24

Users who migrated from a 3.x site that used the versionedfiles module will have its _versions folders left as artefacts in their public filesystems, leaving all the unpublished versions of old files publicly accessible under a guessable URL. This module was superseded by the file versioning functionality provided by the core 4.x recipe, meaning these _versions folders have no ongoing functional utility and should be deleted or blocked from web requests.
Base CVSS Score: 5.9
CWP CVSS Score: 5.9
Thanks to Charlie Bergthaler and Jakub Dolba (SilverStripe Ltd) for reporting this issue.
CVE-2019-14273 Broken Access control on files

Severity:

Low (?)

Identifier:
CVE-2019-14273

Versions Affected:
^4.0

Versions Fixed:
4.3.5, 4.4.4

Release Date:
2019-09-24

Unauthenticated users can access files which with restricted view permissions when embedded in content. This does not affect draft files, or files which aren't embedded in content.
In SilverStripe 4.x and CWP 2.x, files have a draft stage, and can be published. Before publication, they are only accessible to CMS users with access to view draft content (as well as administrators). Separately, published files can be placed in protected folders, with view and edit permissions restricted by certain CMS user groups only ("protected files").
Files can be embedded into other content managed through the CMS, as images or links. Publishing this content will automatically publish these embedded files. If these files are protected (viewable by certain CMS user groups), direct access to the file URL will be denied even for if the file is published. But when accessing the file through linked in the published content, access will be granted without further permission checks.
Base CVSS Score: 3.5
CWP CVSS Score: 3.5
Thanks to Normann Lou for reporting this issue.
2020-04-15 update: Migration task now available
The Silverstripe CMS 4.4.6/4.5.2 release include some additional remedial work related to this vulnerability. A file migration task has been created to retroactively protect files exposed by this vulnerability.
Read the Silverstripe CMS 4.4.6 change log for further details.
CVE-2019-14272 XSS in file titles managed through the CMS

Severity:

Medium (?)

Identifier:
CVE-2019-14272

Versions Affected:
^4.0

Versions Fixed:
4.3.5, 4.4.4

Release Date:
2019-09-24

SilverStripe allows XSS by authenicated users through editing file titles through the CMS. This can lead to privilege escalation by malicious authenticated users with otherwise more limited access.
The CMS generally allows file upload through the CMS for authenticated users (through rich text content editing, or the "assets" section). It is common to add custom file uploads to the CMS UI for authenticated users as well. In some cases, file upload is allowed by unauthenticated users on the website itself (e.g. as attachments through the popular "userforms" module).
Files have titles which are different from their filenames. By default, these titles can only be edited in the CMS. When files are uploaded by unauthenticated users, it is common practice to derive the file title from the sanitised file name, which is not vulnerable to the same XSS flaw.
CWP CVSS Score: 4.9
Thanks to Bot Kotatu for reporting

Security Releases

CVE-2021-28661 Default GraphQL permission checker not inherited by query subclass

CVE-2021-25817 XXE Vulnerability in CSSContentParser

CVE-2020-26138 FormField with square brackets in field name skips validation

CVE-2020-26136 GraphQL doesn't honour MFA when using basic auth

CVE-2021-27938 XSS in CreateQueuedJobTask

CVE-2020-9311 Malicious user profile information can cause login form XSS

CVE-2020-9309 Script execution on protected files with MIME spoofing content

CVE-2020-6165 Limited queries break CanViewPermissionChecker

CVE-2020-6164 Information disclosure on /interactive URL path

CVE-2019-19326 Web Cache Poisoning through HTTPRequestBuilder

CVE-2020-9280 Folders migrated from 3.x may be unsafe to upload to

CVE-2019-19325 XSS through non-scalar FormField attributes

CVE-2019-16409 secureassets and versionedfiles modules can expose versions of protected files

CVE-2019-14273 Broken Access control on files

2020-04-15 update: Migration task now available

CVE-2019-14272 XSS in file titles managed through the CMS