Silverstripe Assets EUVD-2026-23275

Exploitation requires that the Silverstripe site uses the "protected" file visibility setting - files set to "public" are not affected since there is no permission boundary to bypass. The vulnerable code path fires when templates render images stored via DBFile (including standard Silverstripe File/Image DataObjects) using manipulation methods such as ScaleWidth(), FitMax(), or Convert(), which internally invoke DBFile::getURL() or DBFile::getSourceURL(). No authentication is required; any unauthenticated HTTP session that causes a protected image variant to be generated triggers the grant. Sites that do not use protected file visibility at all, or that do not render image variants in templates, are not exposed. The scope of exposed content is limited to files the incorrect grant covers - typically the specific image variant rendered, not arbitrary files.

The CVSS 5.3 Medium score with vector AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N signals a low-complexity, unauthenticated, network-exploitable flaw, but impact is bounded to partial confidentiality loss. EPSS at 0.03% (8th percentile) and SSVC exploitation status of "none" both confirm no observed active exploitation, making this a lower real-world priority than the network-accessible CVSS vector alone might imply. The SSVC automatable flag (yes) indicates the access grant can be triggered predictably and at scale - any unauthenticated page request that causes image variant rendering fires the vulnerable code path - which is a meaningful amplifier. Technical impact is partial: only files under "protected" visibility are exposed, limiting scope to sites that actually configure file protection. No conflict between data sources is observed; all signals are internally consistent. Patch versions are confirmed and available, making remediation straightforward.

An unauthenticated visitor loads a public-facing Silverstripe page that renders a protected image in its template. The template call invokes ScaleWidth() to generate a resized variant, which internally triggers DBFile::getURL(); the module incorrectly writes a session-level access grant. The attacker's browser session now holds an authorization token for that protected file and any variant derived from it, enabling direct retrieval of the asset URL without legitimate permission. No exploit code is publicly available, but the attack is fully automatable via any standard HTTP client.