Silverstripe UserForms: Remote code execution via userforms email subject

Silverstripe UserForms provides a visual form builder for the Silverstripe CMS. From 6.0.0 until 6.4.9, 7.0.7, and 7.1.1, the userform email recipient subject field in the CMS accepts a specially crafted payload that can be interpreted as executable server-side code. An authenticated CMS user with permission to configure a UserForms email recipient can use the subject field to run arbitrary code on the server, compromising confidentiality, integrity, and availability. This issue is fixed in versions 6.4.9, 7.0.7, and 7.1.1.

Silverstripe Versioned: XSS in archive admin restore

Silverstripe Versioned provides versioning for Silverstripe models. Prior to 3.2.1, RestoreAction::getRestoreMessage() in src/RestoreAction.php builds ArchiveAdmin restore notifications rendered as CAST_HTML and inserts $restoredItem->Title, $restoredItem->URLSegment, $restoredItem->CMSEditLink(), and $changedProperty['value'] without applying Convert::raw2xml(). When an administrator restores an archived page containing a crafted title or URL segment, the generated restoration message can execute stored JavaScript in the administrator's browser, compromising the confidentiality and integrity of the CMS session. This issue is fixed in version 3.2.1.

Silverstripe Advanced Workflow: Remote code execution via advanced workflow email template

Silverstripe Advanced Workflow is a highly configurable step-based workflow module. Prior to 6.4.5, 7.1.3, and 7.2.1, an attacker with permission to author the advanced workflow email template can place a specially crafted server-side template payload in NotifyUsersWorkflowAction.EmailTemplate. When NotifyUsersWorkflowAction renders the field through the Silverstripe template engine SSTemplateParser, the payload can cause PHP evaluation and arbitrary code execution on the server; the regression coverage is in tests/php/WorkflowEngineTest.php. This issue is fixed in versions 6.4.5, 7.1.3, and 7.2.1.

Silverstripe: XSS in breadcrumbs in page list view

Silverstripe CMS is an open source content management system. Prior to 6.2.1, page breadcrumbs in the CMS are vulnerable to cross-site scripting when viewed using the page list view, because page titles are rendered into the breadcrumb trail without being escaped. This issue is fixed in 6.2.1.

Silverstripe Framework: Possible XSS attack through media embed

Silverstripe Framework is a PHP framework which powers the Silverstripe CMS. In versions prior to 6.2.2, the "Insert media from web" functionality in the CMS is vulnerable to XSS from a specially crafted embed. This issue was fixed in version 6.2.2/

SQL injection vulnerability in File::find (filesystem/File.php) in SilverStripe before 2.3.1 allows remote attackers to execute arbitrary SQL commands via the filename parameter.

SQL injection vulnerability in SilverStripe before 2.2.2 allows remote attackers to execute arbitrary SQL commands via unspecified vectors related to AjaxUniqueTextField.

Unspecified vulnerability in the search functionality in SilverStripe 2.0.0 has unknown impact and attack vectors.

Silverstripe Assets Module has a DBFile::getURL() permission bypass

The Silverstripe Assets Module is a required component of Silverstripe Framework. In versions prior to 2.4.5 and 3.0.0-rc1 through 3.1.2, images rendered in templates or otherwise accessed via DBFile::getURL() or DBFile::getSourceURL() incorrectly add an access grant to the current session, which bypasses file permissions. This usually happens when creating an image variant, for example using a manipulation method like ScaleWidth() or Convert(). Note that if developers use DBFile directly in the $db configuration for a DataObject class that doesn't subclass File, and if they were setting the visibility of those files to "protected", those files will now need an explicit access grant to be accessed. If developers do not want to explicitly provide access grants for these files in their apps (i.e. they want these files to be accessible by default), they should use the "public" visibility. This issue has been fixed in versions 2.4.5 and 3.1.3.

Cross-site Scripting via insert media remote file oembed in silverstripe-asset-admin

silverstripe-asset-admin is a silverstripe assets gallery for asset management. 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. This issue has been addressed in silverstripe/framework version 5.3.8 and users are advised to upgrade. There are no known workarounds for this vulnerability.

Cross-site Scripting in form messages in silverstripe framework

Silverstripe Framework is a PHP framework which powers the Silverstripe CMS. 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. This issue has been addressed in silverstripe/framework version 5.3.8 and users are advised to upgrade. There are no known workarounds for this vulnerability.

Silverstripe Framework has a XSS vulnerability in HTML editor

Silverstripe Framework is a PHP framework which powers the Silverstripe CMS. Prior to 5.3.23, 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 sanitized on the client-side, but server-side sanitization doesn't catch it. The server-side sanitization logic has been updated to sanitize against this attack. This vulnerability is fixed in 5.3.23.

Cross-site Scripting vulnerability with encoded payload in silverstripe/framework

Silverstripe framework is the PHP framework forming the base for the Silverstripe CMS. In affected versions a bad actor with access to edit content in the CMS could add 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 in version 5.2.16. All users are advised to upgrade. There are no known workarounds for this vulnerability.

Reports are still accessible even when `canView()` returns false in silverstripe/reports

silverstripe/reports is an API for creating backend reports in the Silverstripe Framework. In affected versions reports can be accessed by their direct URL by any user who has access to view the reports admin section, even if the `canView()` method for that report returns `false`. This issue has been addressed in version 5.2.3. All users are advised to upgrade. There are no known workarounds for this vulnerability.

No permission checks for editing/deleting records with CSV import form

Silverstripe Admin provides a basic management interface for the Silverstripe Framework. In versions on the 1.x branch prior to 1.13.19 and on the 2.x branch prior to 2.1.8, users who don't have edit or delete permissions for records exposed in a `ModelAdmin` can still edit or delete records using the CSV import form, provided they have create permissions. The likelihood of a user having create permissions but not having edit or delete permissions is low, but it is possible. Note that this doesn't affect any `ModelAdmin` which has had the import form disabled via the `showImportForm` public property. Versions 1.13.19 and 2.1.8 contain a patch for the issue. Those who have a custom implementation of `BulkLoader` should update their implementations to respect permissions when the return value of `getCheckPermissions()` is true. Those who use any `BulkLoader` in their own project logic, or maintain a module which uses it, should consider passing `true` to `setCheckPermissions()` if the data is provided by users.

Record titles for restricted records can be viewed if exposed by GridFieldAddExistingAutocompleter

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 GraqhQL's view permissions are bypassed for paginated lists of ORM data

The Silverstripe CMS GraphQL Server serves Silverstripe data as GraphQL representations. In versions 4.0.0 prior to 4.3.7 and 5.0.0 prior to 5.1.3, `canView` permission checks are bypassed for ORM data in paginated GraphQL query results where the total number of records is greater than the number of records per page. Note that this also affects GraphQL queries which have a limit applied, even if the query isn’t paginated per se. This has been fixed in versions 4.3.7 and 5.1.3 by ensuring no new records are pulled in from the database after performing `canView` permission checks for each page of results. This may result in some pages in the query results having less than the maximum number of records per page even when there are more pages of results. This behavior is consistent with how pagination works in other areas of Silverstripe CMS, such as in `GridField`, and is a result of having to perform permission checks in PHP rather than in the database directly. One may disable these permission checks by disabling the `CanViewPermission` plugin.

Silverstripe silverstripe/framework through 4.11 allows SQL Injection.

Silverstripe silverstripe/framework through 4.11 allows XSS (issue 2 of 3).

Silverstripe silverstripe/framework through 4.11.0, silverstripe/assets through 1.11.0, and silverstripe/asset-admin through 1.11.0 allow XSS.