Security Releases
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-2022-38146 URL XSS vulnerability due to outdated jquery in CMS
- Severity:
- Medium (?)
- Identifier:
- CVE-2022-38146
- Versions Affected:
- silverstripe/admin: ^1.0.0
- Versions Fixed:
- silverstripe/admin: ^1.11.3
- Release Date:
- 2022-11-21
The Silverstripe CMS UI uses jQuery 1.7.2. This version of jQuery is affected by CVE-2019-11358 Object.prototype pollution. An attacker could perform an XSS attack by convincing a user to follow a link with a specially crafted
__proto__
query string parameter.silverstripe/admin 1.11.3 addresses this problem by stopping all JavaScript execution if a
__proto__
query string is present in the URL. This fix is just a stopped gap measure.This issue will be properly remediated by upgrading to jQuery 3.6.1 or later in the Silverstripe CMS 4.12.0 release.
Most projects should be able to apply the patch without further work. There's no legitimate use case for this behaviour.
Regression testing should focus on custom CMS UI functionality that might be implemented in your project.
If you use the jQuery version distributed with Silverstripe CMS in the front end of your site, you may be affected by this vulnerability via the front end. If this applies to youp project, you should upgrade your theme to use a more recent jQuery version.
Base CVSS: 5.4
Reported by: Trong Pham via huntr.dev
-
CVE-2022-38145 Stored XSS in Compare Mode
- Severity:
- Medium (?)
- Identifier:
- CVE-2022-38145
- Versions Affected:
- silverstripe/versioned-admin: ^1.0.0
- Versions Fixed:
- silverstripe/versioned-admin: ^1.11.1
- Release Date:
- 2022-11-21
A malicious content author could add a Javascript payload to a page's meta description and get it executed in the versioned history compare view.
This vulnerability requires access to the CMS to be deployed. The attacker must then convince a privileged user to access the version history for that page.
Most projects should be able to apply the patch without further work. There's no legitimate use case for this behaviour.
Regression testing should focus on version comparison with the page history tab.
Base CVSS: 4.6
Reported by: TF1T via huntr.dev
-
CVE-2022-37430 Stored XSS using uppercase characters in HTMLEditor
- Severity:
- Medium (?)
- Identifier:
- CVE-2022-37430
- Versions Affected:
- silverstripe/framework: ^3.0.0, ^4.0.0
- Versions Fixed:
- silverstripe/framework: 4.11.13
- Release Date:
- 2022-11-21
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 thehref
attribute.
An attacker must have access to the CMS to exploit this issue.Most projects should be able to apply the patch without further work. There's no legitimate use case for this behaviour.
Regression testing should focus on link creations within HTML editor fields.
Base CVSS: 4.6
Reported by: Steve Boyd from Silverstripe Ltd
-
CVE-2022-37429 Stored XSS using HTMLEditor
- Severity:
- Medium (?)
- Identifier:
- CVE-2022-37429
- Versions Affected:
- silverstripe/framework: ^4.0.0, ^3.0.0
- Versions Fixed:
- silverstripe/framework: 4.11.13
- Release Date:
- 2022-11-21
A malicious content author could add a JavaScript payload to the
href
attribute of a link by splitting ajavascript
URL with white space characters.An attacker must have access to the CMS to exploit this issue.
Most projects should be able to apply the patch without further work. There's no legitimate use case for this behaviour.
Regression testing should focus on link creations within HTML editor fields.
Base CVSS: 4.6
Reported by: TF1T via huntr.dev
-
CVE-2022-37421 Stored XSS in custom meta tags
- Severity:
- Low (?)
- Identifier:
- CVE-2022-37421
- Versions Affected:
- silverstripe/cms: ^4.0.0, ^3.0.0
- Versions Fixed:
- silverstripe/cms: 4.11.3
- Release Date:
- 2022-11-21
A malicious content author could create a custom meta tag and execute an arbitrary JavaScript payload. This would require convincing a legitimate user to access a page and enter a custom keyboard shortcut.
This requires CMS access to exploit.Most projects should be able to apply the patch without further work. There's no legitimate use case for this behaviour.
Regression testing should focus on pages with pre-existing custom meta tags, if any are present.
Base CVSS: 3.7
Reported by: TF1T via huntr.dev
-
CVE-2022-29858 - Unpublished, protected files can be published via shortcode
- Severity:
- Medium (?)
- Identifier:
- CVE-2022-29858
- Versions Affected:
- silverstripe/assets: <=1.10.0
- Versions Fixed:
- silverstripe/assets: 1.10.1
- Release Date:
- 2022-06-28
Draft protected images can be published by changing an existing image shortcode on website content to match the ID of the draft protected image and then publishing the website content.
Base CVSS: 4.3
Reported by: ranjit-git via huntr.dev
-
CVE-2022-28803 - Stored XSS in link tags added via XHR
- Severity:
- Medium (?)
- Identifier:
- CVE-2022-28803
- Versions Affected:
- silverstripe/framework: <=4.10.8
- Versions Fixed:
- silverstripe/framework: 4.10.9
- Release Date:
- 2022-06-28
XSS inside the href attribute of an HTML hyperlink can be added to website content via XHR by an authenticated CMS user.
Base CVSS: 5.4
Reported by: ranjit-git via huntr.dev
-
CVE-2022-25238 - Stored XSS via HTML fields
- Severity:
- Medium (?)
- Identifier:
- CVE-2022-25238
- Versions Affected:
- silverstripe/framework: <=4.10.8
- Versions Fixed:
- silverstripe/framework: 4.10.9
- Release Date:
- 2022-06-28
XSS inside of script tags 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.
Base CVSS: 5.4
Reported by: Greg Best from Aura Information Security
-
CVE-2022-24444 - Hybridsessions does not expire session id on logout
- Severity:
- Medium (?)
- Identifier:
- CVE-2022-24444
- Versions Affected:
- silverstripe/hybridsessions: <=2.4.0, 2.5.0
- Versions Fixed:
- silverstripe/hybridsessions: 2.4.1, 2.5.1
- Release Date:
- 2022-06-28
When using the hybridsessions module is used without the session-manager module installed and sessions IDs are saved to disk, unexpired SessionIDs of logged out users can still be used to make authenticated requests.
Base CVSS: 4.8
Reported by: Kartik Patel
-
CVE-2021-41559 - Quadratic blowup in Convert::xml2array()
- Severity:
- Medium (?)
- Identifier:
- CVE-2021-41559
- Versions Affected:
- silverstripe/framework: <=4.10.8
- Versions Fixed:
- silverstripe/framework: 4.10.9
- Release Date:
- 2022-06-28
The Convert::xml2array() function is vulnerable to quadratic blowup where a malicious xml doctype with internal entities can cause CPU usage to go to 100% and stay there.
Base CVSS: 4.8
Reported by: Matthew Dekker from ZX Security
-
CVE-2022-29254 Failed payment recorded has completed
- Severity:
- Low (?)
- Identifier:
- CVE-2022-29254
- Versions Affected:
- silverstripe/silverstripe-omnipay: <=2.5.1, <=3.0.1, <=3.1.3, <=3.2.0
- Versions Fixed:
- silverstripe/silverstripe-omnipay: 2.5.2, 3.0.2, 3.1.4, 3.2.1
- Release Date:
- 2022-06-06
For a subset of Omnipay gateways (those that use intermediary states like
isNotification()
orisRedirect()
), if the payment identifier or success URL is exposed it is possible for payments to be prematurely marked as completed without payment being taken. This is mitigated by the fact that most payment gateways hide this information from users, however some issuing banks offer flawed 3DSecure implementations that may inadvertently expose this data. -
CVE-2021-36150 - Insert from files link text - Reflective (self) Cross Site Scripting
- Severity:
- Medium (?)
- Identifier:
- CVE-2021-36150
- Versions Affected:
- silverstripe/admin: ^1.0
- Versions Fixed:
- silverstripe/admin: ^1.8.1, silverstripe/admin: ^1.9.0
- Release Date:
- 2021-10-05
A reflective cross-site-script vulnerability exists where if an unwitting CMS user is tricked into pasting HTML containing script tags into a particular CMS form field, arbitrary javascript can be run inside the users browser.
Base CVSS: 4.0
CWP CVSS: 4.0
-
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