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.

• SS-2025-001 User enumeration via timing attack

  Severity:

  Medium (?)

  Identifier:

  SS-2025-001

  Versions Affected:

  silverstripe/framework: <5.3.23

  Versions Fixed:

  silverstripe/framework: 5.3.23

  Release Date:

  2025-04-10

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

  This was originally disclosed in https://www.silverstripe.org/download/security-releases/ss-2017-005/ for CMS 3 but was not patched in CMS 4+

  Base CVSS: 5.3
  
  

• CVE-2025-30148 XSS vulnerability in HTML editor

  Severity:

  Medium (?)

  Identifier:

  CVE-2025-30148

  Versions Affected:

  silverstripe/framework: <5.3.23

  Versions Fixed:

  silverstripe/framework: 5.3.23

  Release Date:

  2025-04-10

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

  Base CVSS: 5.4
  Reported by: James Nicoll from Fujitsu Cyber

• CVE-2025-25197 XSS attack in elemental "Content blocks in use" report

  Severity:

  Medium (?)

  Identifier:

  CVE-2025-25197

  Versions Affected:

  dnadesign/silverstripe-elemental: <5.3.12

  Versions Fixed:

  dnadesign/silverstripe-elemental: 5.3.12

  Release Date:

  2025-04-10

  An elemental block can include an XSS payload, which can be executed when viewing the "Content blocks in use" report.

  The vulnerability is specific to that report and is a result of failure to cast input prior to including it in the grid field.

  Base CVSS: 5.4
  Reported by: Guy Sartorelli from Silverstripe Ltd.

• SS-2024-002 Reflected Cross Site Scripting (XSS) in error message

  Severity:

  None (?)

  Identifier:

  SS-2024-002

  Versions Affected:

  silverstripe/framework: <5.3.8

  Versions Fixed:

  silverstripe/framework: 5.3.8

  Release Date:

  2025-01-15

  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.

  Base CVSS: 0.0
  Reported by: Gaurav Nayak from Chaleit

• CVE-2024-53277 XSS in form messages

  Severity:

  Medium (?)

  Identifier:

  CVE-2024-53277

  Versions Affected:

  silverstripe/framework: <5.3.8

  Versions Fixed:

  silverstripe/framework: 5.3.8

  Release Date:

  2025-01-15

  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.

  Base CVSS: 5.4
  Reported by: Leo Diamat from Bastion Security Group

• CVE-2024-47605 XSS via insert media remote file oembed

  Severity:

  Medium (?)

  Identifier:

  CVE-2024-47605

  Versions Affected:

  silverstripe/framework: <5.3.8

  Versions Fixed:

  silverstripe/framework: 5.3.8

  Release Date:

  2025-01-15

  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.

  See https://docs.silverstripe.org/en/developer_guides/forms/field_types/htmleditorfield/#sandboxing-oembed-html for details about configuring embed sandboxing.

  Base CVSS: 5.4
  Reported by: James Nicoll from Fujitsu Cyber Security Services

• SS-2024-001 TinyMCE allows svg files linked in object tags

  Severity:

  Medium (?)

  Identifier:

  SS-2024-001

  Versions Affected:

  silverstripe/framework: <5.2.16

  Versions Fixed:

  silverstripe/framework: 5.2.16

  Release Date:

  2024-07-17

  TinyMCE v6 has a configuration value convert_unsafe_embeds set to false which allows svg files containing javascript to saved which can be used as a vector for XSS attacks
  
  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 page is saved, which may break any pages that rely upon previously saved object tags. Users are to override this config if desired so that object tags are again used instead of iframes. Note that embed tags are not allowed by default.
  We reviewed the potential impact of this vulnerability within the context of Silverstripe CMS. We concluded this is a medium impact vulnerability given how TinyMCE is used by Silverstripe CMS.

  This vulnerability was described by TinyMCE as follows:

  A cross-site scripting (XSS) vulnerability was discovered in TinyMCE’s content loading and content inserting code. A SVG image could be loaded though an object or embed element and that image could potentially contain a XSS payload.

  Base CVSS: 5.4
  Reported by: Steve Boyd - Silverstripe CMS Squad

  References

  • TinyMCE allows svg files linked in object tags
  • TinyMCE Cross-Site Scripting (XSS) vulnerability in handling external SVG files through Object or Embed elements

• CVE-2024-32981 XSS Vulnerability with text/html base64-encoded payload

  Severity:

  Medium (?)

  Identifier:

  CVE-2024-32981

  Versions Affected:

  silverstripe/framework: <5.2.16

  Versions Fixed:

  silverstripe/framework: 5.2.16

  Release Date:

  2024-07-17

  A specially crafted XSS payload could be inserted into a field in the CMS when logged in as a CMS user with regular permissions. This XSS could be executed either in the CMS or on the front-end of the website.

  Base CVSS: 5.4
  Reported by: Jack Wallace from Bastion Security

  References

  • XSS vulnerability with encoded payload

• CVE-2024-29885 Reports are still accessible even when canView is set to false

  Severity:

  Medium (?)

  Identifier:

  CVE-2024-29885

  Versions Affected:

  silverstripe/reports: <5.2.3

  Versions Fixed:

  silverstripe/reports: 5.2.3

  Release Date:

  2024-07-17

  The `Report` class has a `canView` method. If that method is configured to return `false`, the current user should not be able to view the report. While the report list will omit any `canView` `false` reports, those reports can still access them directly assuming the user has the `CMS_ACCESS_ReportAdmin` permission.
  
  After patching the `canView` check will be properly respected

  Base CVSS: 4.3
  Reported by: Nate Devereux and Fiona Black from Silverstripe Ltd.

  References

  • Reports are still accessible even when `canView()` returns false

• CVE-2023-49783 - No permission checks for editing or deleting records with CSV import form

  Severity:

  Medium (?)

  Identifier:

  CVE-2023-49783

  Versions Affected:

  silverstripe/admin: ^1, ^2

  Versions Fixed:

  silverstripe/admin: 1.13.19, 2.1.8

  Release Date:

  2024-01-23

  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 likelyhood 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, nor does it impact the SecurityAdmin section.

  Action may be required

  If you have a custom implementation of BulkLoader, you should update your implementation to respect permissions when the return value of getCheckPermissions() is true.

  If you are using any BulkLoader in your own project logic, or maintain a module which uses it, you should consider passing true to setCheckPermissions() if the data is provided by users.

  Base CVSS: 4.3
  Reported by: Guy Sartorelli from Silverstripe

• CVE-2023-48714 - Record titles for restricted records can be viewed if exposed by GridFieldAddExistingAutocompleter

  Severity:

  Medium (?)

  Identifier:

  CVE-2023-48714

  Versions Affected:

  silverstripe/framework: ^3, ^4, ^5

  Versions Fixed:

  silverstripe/framework: 4.11.39, 5.1.11

  Release Date:

  2024-01-23

  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.

  Base CVSS: 4.3
  Reported by: Nick K - LittleMonkey, littlemonkey.co.nz

• CVE-2023-44401 - View permissions are bypassed for paginated lists of ORM data in GraphQL queries

  Severity:

  Medium (?)

  Identifier:

  CVE-2023-44401

  Versions Affected:

  silverstripe/graphql: ^4, ^5

  Versions Fixed:

  silverstripe/graphql: 4.3.7, 5.1.3

  Release Date:

  2024-01-23

  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 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 your query results having less than the maximum number of records per page even when there are more pages of results.

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

  You can choose to disable these permission checks by disabling the CanViewPermission plugin following the instructions in overriding default plugins.

  Note that this vulnerability does not affect silverstripe/graphql version 3.x.

  Base CVSS: 5.3
  Reported by: Eduard Briem from Hothouse Creative, Nelson

• CVE-2023-40180 - DDOS Vulnerability on GraphQL due to lack of protection against recursive queries

  Severity:

  High (?)

  Identifier:

  CVE-2023-40180

  Versions Affected:

  silverstripe/graphql: ^3.0.0, ^4.0.0, ^5.0.0

  Versions Fixed:

  3.8.2, 4.1.3, 4.2.5, 4.3.4, 5.0.3

  Release Date:

  2023-10-16

  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.

  The fix includes some new configuration options which you might want to tweak for your project, based on your own requirements. See the documentation in the references for details.

  Base CVSS: 7.5

  Reported by: Jason Nguyen from phew

  References

  • Documentation about protection against recursive or complex queries for silverstripe/graphql 4.x/5.x
  • Documentation about protection against recursive or complex queries for silverstripe/graphql 3.x

• SS-2023-002 Cross-site scripting (XSS) vulnerabilities inherited form TinyMCE

  Severity:

  Medium (?)

  Identifier:

  SS-2023-002

  Versions Affected:

  silverstripe/admin: ^1.0.0

  Versions Fixed:

  silverstripe/admin: ^1.13.6

  Release Date:

  2023-07-31

  TinyMCE 4.x is vulnerable to several XSS vectors, which had been patched in later versions. Two of these have been identified as affecting silverstripe/admin.

  Only Silverstripe CMS 4 is affected by these vulnerabilities. It's not possible to upgrade Silverstripe CMS 4 to use a more recent release of TinyMCE without introducing breaking changes. Instead, the security patches that shipped in later releases of TinyMCE have been backported to the TinyMCE version bundled in silverstripe/admin.

  Silverstripe CMS 5 is not affected by these vulnerabilities because it uses TinyMCE 6.

  These vulnerabilities were described by TinyMCE:

  A cross-site scripting (XSS) vulnerability was discovered in the schema validation logic of the core parser. The vulnerability allowed arbitrary JavaScript execution when inserting a specially crafted piece of content into the editor using the clipboard or editor APIs. This malicious content could then end up in content published outside the editor, if no server-side sanitization was performed. This impacts all users who are using TinyMCE 5.8.2 or lower.
  
  A cross-site scripting (XSS) vulnerability was discovered in the URL sanitization logic of the core parser. The vulnerability allowed arbitrary JavaScript execution when inserting a specially crafted piece of content into the editor using the clipboard or APIs. This impacts all users who are using TinyMCE 5.5.1 or lower.

  Base CVSS: 5.4
  Reported by: Guy Sartorelli from Silverstripe

  References

  • GHSA-5h9g-x5rv-25wg Cross-site scripting vulnerability in TinyMCE
  • GHSA-w7jx-j77m-wp65 Cross-site scripting vulnerability in TinyMCE

• CVE-2023-32302 Members with no password can be created and bypass custom login forms

  Severity:

  None (?)

  Identifier:

  CVE-2023-32302

  Versions Affected:

  silverstripe/framework: ^3, ^4, ^5

  Versions Fixed:

  silverstripe/framework: 4.13.14, 5.0.13

  Release Date:

  2023-07-31

  When a new Member record was created in the cms it was possible to set a blank password. If an attacker knows the email address of the user with the blank password then they can attempt to log in using an empty password. The default member authenticator, login form and basic auth all require a non-empty password, however if a custom authentication method is used it may allow a successful login with the empty password.

  After being patched, blank passwords are no no longer allowed when members are created in the CMS. Programatically created Member records, such as those used in unit tests, still allow blank passwords.

  You may have some Member records in your system already which have empty passwords. To detect these, you can loop over all Member records with Member::get() and pass each record into the below method. It might be sensible to create a BuildTask for this purpose.

  use SilverStripe\Security\Member;
  use SilverStripe\Security\MemberAuthenticator\MemberAuthenticator;
  
  private function memberHasBlankPassword(Member $member): bool
  {
      // skip default admin as this is created programatically
      if ($member->isDefaultAdmin()) {
          return false;
      }
      // return true if a blank password is valid for this member
      $authenticator = new MemberAuthenticator();
      return $authenticator->checkPassword($member, '')->isValid();
  }

  Once you have identified the records with empty passwords, it's up to you how to handle this. The most sensible way to resolve this is probably to generate a new secure password for each of these members, mark it as immediately expired, and email each affected member (assuming they have a valid email address in the system).

  Base CVSS: 0.0
  Reported by: Sabina Talipova from Silverstripe and Christian Bünte

  Addendum - November 2, 2023

  CVE-2023-32302 has been invalidated. Following discussions with the National Institute of Standards and Technology (NIST), it was determined that entries in the National Vulnerability Database can not have a CVSS of 0.

  While CVE-2023-32302 is no longer a valid vulnerability identifier, the rest of the information on this page remains relevant.

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• Next