EUVD-2026-23275
GHSA-jgcf-rf45-2f8v
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Network-reachable via standard template rendering, no authentication or user interaction needed; impact is read-only access to protected files, no integrity or availability consequence.
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
Lifecycle Timeline
6DescriptionGitHub Advisory
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.
AnalysisAI
Protected file access bypass in Silverstripe Assets Module allows unauthenticated remote visitors to read files that should be restricted by the CMS file permission system. When image variants are generated via template rendering - for example calling ScaleWidth() or Convert() - the DBFile::getURL() and DBFile::getSourceURL() methods incorrectly insert an access grant into the current HTTP session, nullifying the "protected" visibility setting for those files. Versions prior to 2.4.5 and 3.0.0-rc1 through 3.1.2 are affected; patches exist at 2.4.5 and 3.1.3. No public exploit has been identified at time of analysis, and EPSS is very low at 0.03%, but SSVC flags the attack as automatable.
Technical ContextAI
Silverstripe Assets is a required Composer package (silverstripe/assets) for the Silverstripe CMS Framework, responsible for managing file storage, access control, and image manipulation. The module supports two visibility modes - "public" and "protected" - where protected files require an explicit access grant before a session can retrieve them. CWE-863 (Incorrect Authorization) identifies the root cause: the session-based grant mechanism fires incorrectly during image variant creation. Specifically, when DBFile::getURL() or DBFile::getSourceURL() is called - as happens automatically when Silverstripe templates invoke manipulation methods like ScaleWidth() or Convert() - the module writes a session-level access grant without verifying whether the requesting user is authorized to view the underlying protected asset. The CPE string cpe:2.3:a:silverstripe:silverstripe-assets covers the affected package across both the 2.x and 3.x release lines.
RemediationAI
Upgrade silverstripe/assets to version 2.4.5 (for 2.x deployments) or 3.1.3 (for 3.x deployments) via Composer: composer update silverstripe/assets. Full vendor guidance is at https://www.silverstripe.org/download/security-releases/cve-2026-24749. Post-upgrade, developers who use DBFile directly in $db configurations on DataObject classes that do not subclass File and had set those files to "protected" visibility must now add explicit access grants in application code, since the incorrect implicit grant will no longer fire. If explicit grants are undesirable, change those file fields to "public" visibility - note this trade-off makes the files publicly readable without any session check. No workaround that avoids template image rendering is practical for most sites; patching is the only reliable remediation.
Same weakness CWE-863 – Incorrect Authorization
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today