<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Thu, 08 Oct 2026 16:39:22 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-291875</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-291875</link>
      <description>EUVD-2026-291875</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-291875</guid>
    </item>
    <item>
      <title>fkie_cve-2026-24749</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-24749</link>
      <description>&lt;p&gt;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&amp;#39;t subclass File, and if they were setting the visibility of those files to &amp;#34;protected&amp;#34;, 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 &amp;#34;public&amp;#34; visibility. This issue has been fixed in versions 2.4.5 and 3.1.3.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;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&amp;#39;t subclass File, and if they were setting the visibility of those files to &amp;#34;protected&amp;#34;, 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 &amp;#34;public&amp;#34; visibility. This issue has been fixed in versions 2.4.5 and 3.1.3.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-24749</guid>
    </item>
    <item>
      <title>GHSA-jgcf-rf45-2f8v — Silverstripe Assets Module has a DBFile::getURL() permission bypass</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-jgcf-rf45-2f8v</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Packagist: silverstripe/assets&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;This usually happens when creating an image variant, for example using a manipulation method like `ScaleWidth()` or `Convert()`.&lt;/p&gt;
&lt;p&gt;Note that if you use `DBFile` directly in the `$db` configuration for a `DataObject` class that doesn&amp;#39;t subclass `File`, and if you were setting the visibility of those files to &amp;#34;protected&amp;#34;, those files will now need an explicit access grant to be accessed. If you do not want to explicitly provide access grants for these files (i.e. you want these files to be accessible by default), you should use the &amp;#34;public&amp;#34; visibility.&lt;/p&gt;
&lt;p&gt;### Reported by&lt;/p&gt;
&lt;p&gt;Restruct web &amp;amp; apps&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Packagist: silverstripe/assets&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;This usually happens when creating an image variant, for example using a manipulation method like `ScaleWidth()` or `Convert()`.&lt;/p&gt;
&lt;p&gt;Note that if you use `DBFile` directly in the `$db` configuration for a `DataObject` class that doesn&amp;#39;t subclass `File`, and if you were setting the visibility of those files to &amp;#34;protected&amp;#34;, those files will now need an explicit access grant to be accessed. If you do not want to explicitly provide access grants for these files (i.e. you want these files to be accessible by default), you should use the &amp;#34;public&amp;#34; visibility.&lt;/p&gt;
&lt;p&gt;### Reported by&lt;/p&gt;
&lt;p&gt;Restruct web &amp;amp; apps&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-jgcf-rf45-2f8v</guid>
    </item>
  </channel>
</rss>
