We've released five security patches for Silverstripe CMS to address security vulnerabilities. These vulnerabilities were reported to us following the documented process for reporting security issues.
Two of these vulnerabilities have a severity rating of 'high' and three have a severity rating of 'medium'. The two high-severity vulnerabilities are patched in Silverstripe CMS 5.4, 6.1, and 6.2. The remaining three are patched in Silverstripe CMS 6.2.
See the release process documentation for more information about severity ratings.
High severity
CVE-2026-54721 - Remote code execution via userforms email subject
The silverstripe/userforms module allows CMS users to build forms via the CMS interface. The email subject field for form submission notifications is rendered as a Silverstripe template. The template engine's <%t %> translation block emitted its default and context strings as double-quoted PHP string literals in the compiled template. A CMS user with permission to create user-defined forms could craft an email subject containing a PHP variable-variable expression inside a <%t %> block, which would be evaluated when the template was rendered, resulting in remote code execution on the server.
The patch modifies the template parser to emit default and context strings as single-quoted PHP string literals, which do not interpolate variables or expressions. This fix is applied in silverstripe/framework for Silverstripe CMS 5.4 and in silverstripe/template-engine for Silverstripe CMS 6.1 and CMS 6.2. The silverstripe/userforms module has been updated to require a minimum version of silverstripe/framework or silverstripe/template-engine that includes the fix.
Read the CVE-2026-54721 security advisory for the technical details of this vulnerability.
CVE-2026-54718 - Remote code execution via advanced workflow email template
The symbiote/silverstripe-advancedworkflow module allows CMS users with workflow permissions to configure notification email templates. The email template field is a plain text area whose content is rendered as a Silverstripe template. The same template parser vulnerability described in CVE-2026-54721 allowed a CMS user with permission to create workflows to inject arbitrary PHP via a <%t %> block in the email template, resulting in remote code execution on the server.
This vulnerability uses the same underlying template parser fix as CVE-2026-54721. The fix is applied in silverstripe/framework for Silverstripe CMS 5.4 and in silverstripe/template-engine for Silverstripe CMS 6.1 and CMS 6.2. The symbiote/silverstripe-advancedworkflow module has been updated to require a minimum version of silverstripe/framework or silverstripe/template-engine that includes the fix.
Read the CVE-2026-54718 security advisory for the technical details of this vulnerability.
Medium severity
CVE-2026-54717 - XSS in breadcrumbs in page list view
A stored cross-site scripting (XSS) vulnerability exists in the CMS "Pages" list view. When viewing pages in list mode, ancestor page titles are rendered as part of a breadcrumb trail beneath each page title. These ancestor titles were not properly HTML-escaped before being inserted into the page, which allowed a CMS user with content editing privileges to inject arbitrary JavaScript that would execute in the browser of other CMS users, including administrators.
The patch escapes ancestor page titles before they are included in the breadcrumb HTML fragment.
Read the CVE-2026-54717 security advisory for the technical details of this vulnerability.
CVE-2026-54720 - XSS attack through media embed
Inside the CMS WYSIWYG editor, there is an "insert media from URL" option which allows content to be embedded from external websites using the oEmbed format. A previous patch sandboxed potentially dangerous embeds inside an iframe, but explicitly skipped sandboxing when the embed HTML was already a single iframe element. The iframe markup itself was not sanitised in this case, which meant event-handler attributes such as onload on the iframe would execute JavaScript in the context of the main document.
The patch now strips all attributes from non-sandboxed iframe embeds that are not on a known-safe allowlist. Allowed attributes are limited to those needed by mainstream providers (e.g. src, width, height, allow, allowfullscreen). Event-handler attributes such as onload are removed, as is srcdoc. The src attribute is also removed if it uses a javascript:, data:, vbscript:, or file: scheme.
If this fix causes a legitimate embed to stop working, you can exempt a trusted provider's domain from attribute stripping via YAML configuration:
SilverStripe\View\Shortcodes\EmbedShortcodeProvider:
domains_excluded_from_sandboxing:
- trusted-provider.com
Embeds from that domain will then render exactly as the provider sends them. Only add domains you fully trust, as this also disables iframe sandboxing for that domain.
Read the CVE-2026-54720 security advisory for the technical details of this vulnerability.
CVE-2026-55779 - XSS in archive admin restore
A stored cross-site scripting (XSS) vulnerability exists in the archive admin interface. When a page is restored from the archive, the success message includes the page title without proper HTML escaping. A CMS user could set a page title containing an XSS payload, archive the page, and when any user subsequently restored that page the payload would execute in their browser.
The patch escapes all user-supplied content in the restore message, including the page title, URL segment, and edit link.
Read the CVE-2026-55779 security advisory for the technical details of this vulnerability.
Security patch release windows
The minor release policy includes quarterly release windows for security patches like this one. Read the minor release policy for more information about security patch release windows.
A note for sites on Silverstripe CMS 5.4
Silverstripe CMS 5.4 is in its partial support phase. As described in our release policy, partially-supported releases receive fixes only for high and critical security issues - those with a CVSS score of 7.0 or above. Lower-severity issues are fixed on fully-supported lines only.
That policy applied to this release. The two high-severity vulnerabilities (CVE-2026-54721 and CVE-2026-54718) were patched in CMS 5.4, 6.1 and 6.2. The three medium-severity vulnerabilities were patched in CMS 6.2 only:
- CVE-2026-54717 - XSS in page-list breadcrumbs
- CVE-2026-54720 - XSS via media embed
- CVE-2026-55779 - XSS in archive admin restore
Why this might be impacting you now
Until recently, an unpatched lower-severity advisory on a 5.4 site could easily go unnoticed - the fix simply never arrived and nothing got in your way. In recent times, however, security tooling has become stricter and developer practices are prioritising security more for example:
- roave/security-advisories refuses to install any package version with a known advisory. It has become a common fixture in PHP projects as a simple way to keep vulnerable dependencies out of a project - Packagist records over 100 million installs and roughly 2 million a month.
- Composer 2.9 now does the same natively (config.policy.advisories.block, on by default), blocking during composer require/composer update.
Because the advisory databases flag every version that lacks the fix - including versions on lines where we don't backport it - composer update on an otherwise-healthy 5.4 site can be blocked, with no fixed version available short of a major upgrade. (Exactly how this surfaces depends on your setup: in most cases Composer will stop with an error naming the advisory, but with dev stability settings dependency resolution can behave differently - for example landing on a commit reference rather than a tagged release - so check the behaviour on your own project.) We know this is frustrating, and we want to set out your options clearly.
1. Assess the actual risk first
All three issues patched only in CMS 6.2 are medium-severity stored XSS that require an authenticated CMS user with content-editing or workflow permissions to exploit. If you trust your CMS authors and your editor base is small and controlled, your real-world exposure may be low. Read each advisory and make a deliberate call for your site rather than treating the block as all-or-nothing.
2. Accept the risk and allow specific advisories with Composer >2.9
Composer lets you exempt specific advisory IDs while staying protected against everything else, via config.policy.advisories.ignore-id. Using the on-block: false scope is recommended here because it lifts the install/update block for that advisory but keeps reporting it in composer audit, so you don't lose visibility of the risk you've accepted:
{
"config": {
"policy": {
"advisories": {
"ignore-id": {
"PKSA-pjvm-vnw2-n3m2": {
"on-block": false,
"reason": "CVE-2026-54717 medium XSS (page-list breadcrumbs), not backported to CMS 5.4 (partial support); accepted pending upgrade"
},
"PKSA-x6tz-s6v3-ynk3": {
"on-block": false,
"reason": "CVE-2026-54720 medium XSS (media embed), not backported to CMS 5.4 (partial support); accepted pending upgrade"
},
"PKSA-nksq-cxj8-zb32": {
"on-block": false,
"reason": "CVE-2026-55779 medium XSS (archive admin restore), not backported to CMS 5.4 (partial support); accepted pending upgrade"
}
}
}
}
}
}
Note that ignore-id must be given the Packagist advisory ID - the PKSA-... value. A CVE-... alias is not honoured by the resolver when unblocking an install, even though it shows up in the audit report, so use the PKSA-... form. The quickest way to find it is to run composer audit (or simply attempt the blocked composer update) - Composer prints the exact ID to add, for example:
Found 1 security vulnerability advisory affecting 1 package:
silverstripe/versioned (v2.x) - CVE-2026-55779 - PKSA-nksq-cxj8-zb32
To ignore this advisory, add "PKSA-nksq-cxj8-zb32" to the "ignore-id" config.
You can also look an advisory up in the Packagist advisories database - for example https://packagist.org/api/security-advisories/?packages[]=silverstripe/versioned returns the advisoryId (the PKSA-... value) alongside its cve. Add one entry per advisory you've consciously accepted, keeping the CVE in the reason for readability. This lifts the block for only those advisories - any new vulnerability still stops the build.
Note on config keys: these settings moved to config.policy.advisories in recent Composer. The older config.audit. keys (e.g. audit.ignore, audit.block-insecure) still work but are deprecated - and are ignored entirely as soon as any config.policy.advisories key is set, so don't mix the two.
3. If you use roave/security-advisories, switch to Composer's native audit
roave/security-advisories works by adding a conflict rule for every vulnerable package version. It draws on the same underlying advisory data that Composer's own audit now uses (the FriendsOfPHP database and the GitHub/Packagist advisory database), so as of Composer 2.9 it is largely the same protection - and it is deliberately all-or-nothing, with no mechanism to exempt an individual advisory. On a partially-supported line that means it will block you with no way through. Composer's native audit covers the same ground _and_ supports the per-advisory ignore-id shown above, so we'd suggest removing the package and relying on the built-in audit.
4. The durable fix is to upgrade
The workarounds above are a deliberate, temporary acceptance of risk - not a substitute for support. The lasting answer is to move to a fully-supported release line (currently CMS 6.x), where these fixes are already present and future low-severity fixes will land normally. We
encourage planning that upgrade rather than carrying ignored advisories indefinitely.
On expanding support
We've heard the feedback that stricter tooling makes partial support harder to live with, and we don't take that lightly. But our policy hasn't changed - these fixes were always going to be absent on 5.4; the tooling has only made it more visible. We're a small team, and backporting every lower-severity fix across older lines isn't something we can sustain without taking away from keeping the supported lines healthy. We'd rather be honest about that than promise support we can't deliver. Thank you for your understanding - and for helping us keep Silverstripe CMS secure.
