silverstripe CVE Vulnerabilities & Metrics

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.

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.

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-graphql is a package which serves Silverstripe data in GraphQL representations. An attacker could use a recursive graphql query to execute a Distributed Denial of Service attack (DDOS attack) against a website. This mostly affects websites with publicly exposed graphql schemas. If your Silverstripe CMS project does not expose a public facing graphql schema, a user account is required to trigger the DDOS attack. If your site is hosted behind a content delivery network (CDN), such as Imperva or CloudFlare, this may further mitigate the risk. This issue has been addressed in versions 3.8.2, 4.1.3, 4.2.5, 4.3.4, and 5.0.3. Users are advised to upgrade. There are no known workarounds for this vulnerability.

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/graphql` serves Silverstripe data as GraphQL representations. In versions 4.2.2 and 4.1.1, an attacker could use a specially crafted graphql query to execute a denial of service attack against a website which has a publicly exposed graphql endpoint. This mostly affects websites with particularly large/complex graphql schemas. Users should upgrade to `silverstripe/graphql` 4.2.3 or 4.1.2 to remedy the vulnerability.

Silverstripe silverstripe/subsites through 2.6.0 has Insecure Permissions.

Silverstripe silverstripe/cms through 4.11.0 allows XSS.

Silverstripe silverstripe/framework through 4.11 allows XSS vulnerability via href attribute of a link (issue 2 of 2).

Silverstripe silverstripe/framework through 4.11 allows XSS (issue 1 of 2) via JavaScript payload to the href attribute of a link by splitting a javascript URL with white space characters.

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

Silverstripe silverstripe/framework through 4.11 is vulnerable to XSS by carefully crafting a return URL on a /dev/build or /Security/login request.

Silverstripe silverstripe/framework through 4.11 allows SQL Injection.

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

In SilverStripe Framework through 2022-04-07, Stored XSS can occur in javascript link tags added via XMLHttpRequest (XHR).

Silverstripe silverstripe/assets through 1.10 is vulnerable to improper access control that allows protected images to be published by changing an existing image short code on website content.

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 through 4.10 allows Session Fixation.

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

silverstripe-omnipay is a SilverStripe integration with Omnipay PHP payments library. For a subset of Omnipay gateways (those that use intermediary states like `isNotification()` or `isRedirect()`), 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. The following versions have been patched to fix this issue: `2.5.2`, `3.0.2`, `3.1.4`, and `3.2.1`. There are no known workarounds for this vulnerability.

Default SilverStripe GraphQL Server (aka silverstripe/graphql) 3.x through 3.4.1 permission checker not inherited by query subclass.

SilverStripe Framework through 4.8.1 allows XSS.

In SilverStripe through 4.6.0-rc1, GraphQL doesn't honour MFA (multi-factor authentication) when using basic authentication.

In SilverStripe through 4.6.0-rc1, a FormField with square brackets in the field name skips validation.

SilverStripe through 4.6.0-rc1 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. (The correct CVE ID year is 2020 [CVE-2020-25817, not CVE-2021-25817]).

In SilverStripe through 4.5, 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.

Silverstripe CMS through 4.5 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.

SilverStripe 4.5.0 allows attackers to read certain records that should not have been placed into a result set. This affects silverstripe/recipe-cms. 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 have failed a permission check being added to the final result set. GraphQL endpoints are configured by default (e.g., for assets), but the admin/graphql endpoint is access protected by default. This limits the vulnerability to all authenticated users, including those with limited permissions (e.g., where viewing records exposed through admin/graphql requires administrator permissions). However, if custom GraphQL endpoints have been configured for a specific implementation (usually under /graphql), this vulnerability could also be exploited through unauthenticated requests. This vulnerability only applies to reading records; it does not allow unauthorised changing of records.

In SilverStripe through 4.5.0, 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).

Silverstripe CMS sites through 4.4.4 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.

In SilverStripe through 4.5, files uploaded via Forms to folders migrated from Silverstripe CMS 3.x may be put to the default "/Uploads" folder instead. 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.

In SilverStripe through 4.3.3, the previous fix for SS-2018-007 does not completely mitigate the risk of CSRF in GraphQL mutations,

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

SilverStripe through 4.4.x before 4.4.5 and 4.5.x before 4.5.2 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 upgrade process automates the destruction of these insecure artefacts, nor alerts the user to the criticality of destruction.)

In SilverStripe assets 4.0, there is broken access control on files.

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

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

SilverStripe through 4.3.3 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.

SilverStripe through 4.3.3 has Flash Clipboard Reflected XSS.

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

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

SQL injection vulnerability in silverstripe/restfulserver module 1.0.x before 1.0.9, 2.0.x before 2.0.4, and 2.1.x before 2.1.2 and silverstripe/registry module 2.1.x before 2.1.1 and 2.2.x before 2.2.1 allows attackers to execute arbitrary SQL commands.

All versions of SilverStripe 3 prior to 3.6.7 and 3.7.3, and all versions of SilverStripe 4 prior to 4.0.7, 4.1.5, 4.2.4, and 4.3.1 allows Reflected SQL Injection through Form and DataObject.

In the CSV export feature of SilverStripe before 3.5.6, 3.6.x before 3.6.3, and 4.x before 4.0.1, it's possible for the output to contain macros and scripts, which may be executed if imported without sanitization into common software (including Microsoft Excel). For example, the CSV data may contain untrusted user input from the "First Name" field of a user's /myprofile page.

Response discrepancy in the login and password reset forms in SilverStripe CMS before 3.5.5 and 3.6.x before 3.6.1 allows remote attackers to enumerate users via timing attacks.

SilverStripe CMS before 3.6.1 has 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, as demonstrated by the admin/pages/edit/EditorToolbar/MediaForm/field/AssetUploadField/upload URI, aka issue SS-2017-017.

There is XSS in SilverStripe CMS before 3.4.4 and 3.5.x before 3.5.2. The attack vector is a page name. An example payload is a crafted JavaScript event handler within a malformed SVG element.

Multiple cross-site scripting (XSS) vulnerabilities in SilverStripe CMS & Framework before 3.1.16 and 3.2.x before 3.2.1 allow remote attackers to inject arbitrary web script or HTML via the (1) Locale or (2) FailedLoginCount parameter to admin/security/EditForm/field/Members/item/new/ItemEditForm.

Multiple cross-site scripting (XSS) vulnerabilities in SilverStripe CMS & Framework 3.1.13 allow remote attackers to inject arbitrary web script or HTML via the (1) admin_username or (2) admin_password parameter to install.php.

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.

Cross-site scripting (XSS) vulnerability in the process function in SSViewer.php in SilverStripe before 2.3.13 and 2.4.x before 2.4.6 allows remote attackers to inject arbitrary web script or HTML via the QUERY_STRING to template placeholders, as demonstrated by a request to (1) admin/reports/, (2) admin/comments/, (3) admin/, (4) admin/show/, (5) admin/assets/, and (6) admin/security/.

security/MemberLoginForm.php in SilverStripe 3.0.3 supports credentials in a GET request, which allows remote or local attackers to obtain sensitive information by reading web-server access logs, web-server Referer logs, or the browser history, a similar vulnerability to CVE-2013-2653.

security/MemberLoginForm.php in SilverStripe 3.0.3 supports login using a GET request, which makes it easier for remote attackers to conduct phishing attacks without detection by the victim.

Multiple cross-site scripting (XSS) vulnerabilities in the SilverStripe e-commerce module 3.0 for SilverStripe CMS allow remote attackers to inject arbitrary web script or HTML via the (1) FirstName, (2) Surname, or (3) Email parameter to code/forms/OrderFormAddress.php; or the (4) FirstName or (5) Surname parameter to code/forms/ShopAccountForm.php.

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 template, different vectors than CVE-2012-0976.

code/sitefeatures/PageCommentInterface.php in SilverStripe 2.4.x before 2.4.6 might allow remote attackers to execute arbitrary code via a crafted cookie in a user comment submission, which is not properly handled when it is deserialized.

SilverStripe 2.3.x before 2.3.12 and 2.4.x before 2.4.6 allows remote authenticated users with the EDIT_PERMISSIONS permission to gain administrator privileges via a TreeMultiselectField that includes admin groups when adding a user to the selected groups.

SQL injection vulnerability in the Folder::findOrMake method in SilverStripe 2.3.x before 2.3.12 and 2.4.x before 2.4.6 allows remote attackers to execute arbitrary SQL commands via unspecified vectors.

SQL injection vulnerability in the addslashes method in SilverStripe 2.3.x before 2.3.12 and 2.4.x before 2.4.6, when connected to a MySQL database using far east character encodings, allows remote attackers to execute arbitrary SQL commands via unspecified vectors.

SilverStripe 2.3.x before 2.3.10 and 2.4.x before 2.4.4 uses weak entropy when generating tokens for (1) the CSRF protection mechanism, (2) autologin, (3) "forgot password" functionality, and (4) password salts, which makes it easier for remote attackers to bypass intended access restrictions via unspecified vectors.

SilverStripe 2.3.x before 2.3.10 and 2.4.x before 2.4.4 stores sensitive information under the web root with insufficient access control, which allows remote attackers to obtain version information via a direct request to (1) apphire/silverstripe_version or (2) cms/silverstripe_version.

SQL injection vulnerability in the augmentSQL method in core/model/Translatable.php in SilverStripe 2.3.x before 2.3.10 and 2.4.x before 2.4.4, when the Translatable extension is enabled, allows remote attackers to execute arbitrary SQL commands via the locale parameter.

Cross-site scripting (XSS) vulnerability in the httpError method in sapphire/core/control/RequestHandler.php in SilverStripe 2.3.x before 2.3.10 and 2.4.x before 2.4.4, when custom error handling is not used, allows remote attackers to inject arbitrary web script or HTML via "missing URL actions."

core/model/MySQLDatabase.php in SilverStripe 2.4.x before 2.4.4, when the site is running in "live mode," allows remote attackers to obtain the SQL queries for a page via the showqueries and ajax parameters.

SilverStripe 2.3.x before 2.3.6 allows remote attackers to obtain sensitive information via the (1) debug_memory parameter to core/control/Director.php or (2) debug_profile parameter to main.php.

SilverStripe 2.3.x before 2.3.8 and 2.4.x before 2.4.1, when running on servers with certain configurations, allows remote attackers to obtain sensitive information via a direct request to PHP files in the (1) sapphire, (2) cms, or (3) mysite folders, which reveals the installation path in an error message.

Cross-site scripting (XSS) vulnerability in SilverStripe 2.3.x before 2.3.6 allows remote attackers to inject arbitrary web script or HTML via vectors related to DataObjectSet pagination.

The deleteinstallfiles function in control/ContentController.php in SilverStripe 2.3.x before 2.3.7 does not require ADMIN permissions, which allows remote attackers to delete index.php and "disrupt mod_rewrite-less URL routing."

Member_ProfileForm in security/Member.php in SilverStripe 2.3.x before 2.3.7 allows remote attackers to hijack user accounts by saving data using the email address (ID) of another user.

The Add Member dialog in the Security admin page in SilverStripe 2.4.0 saves user passwords in plaintext, which allows local users to obtain sensitive information by reading a database.

The setName function in filesystem/File.php in SilverStripe 2.3.x before 2.3.8 and 2.4.x before 2.4.1 allows remote authenticated users with CMS author privileges to execute arbitrary PHP code by changing the extension of an uploaded file.

SilverStripe before 2.4.2 allows remote authenticated users to change administrator passwords via vectors related to admin/security.

SilverStripe before 2.4.2 does not properly restrict access to pages in draft mode, which allows remote attackers to obtain sensitive information.

Multiple cross-site request forgery (CSRF) vulnerabilities in SilverStripe 2.3.x before 2.3.9 and 2.4.x before 2.4.3 allow remote attackers to hijack the authentication of administrators via destructive controller actions, a different vulnerability than CVE-2010-5087.

SilverStripe 2.3.x before 2.3.10 and 2.4.x before 2.4.4 allows remote attackers to bypass the cross-site request forgery (CSRF) protection mechanism and hijack the authentication of administrators via vectors related to "form action requests" using a controller.

The Security/changepassword URL action in SilverStripe 2.3.x before 2.3.10 and 2.4.x before 2.4.4 passes a token as a GET parameter while changing a password through email, which allows remote attackers to obtain sensitive data and hijack the session via the HTTP referer logs on a server, aka "HTTP referer leakage."

Cross-site scripting (XSS) vulnerability in admin/EditForm in SilverStripe 2.4.6 allows remote authenticated users with Content Authors privileges to inject arbitrary web script or HTML via the Title parameter. NOTE: some of these details are obtained from third party information.

Multiple cross-site scripting (XSS) vulnerabilities in SilverStripe before 2.3.5 allow remote attackers to inject arbitrary web script or HTML via (1) the CommenterURL parameter to PostCommentForm, and in the Forum module before 0.2.5 in SilverStripe before 2.3.5 allow remote attackers to inject arbitrary web script or HTML via (2) the Search parameter to forums/search (aka the search script).

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

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.

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