<?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>Fri, 16 Oct 2026 03:10:31 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-225376</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-225376</link>
      <description>EUVD-2026-225376</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-225376</guid>
    </item>
    <item>
      <title>fkie_cve-2025-30350</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-30350</link>
      <description>&lt;p&gt;Directus is a real-time API and App dashboard for managing SQL database content. The `@directus/storage-driver-s3` package starting in version 9.22.0 and prior to version 12.0.1, corresponding to Directus starting in version 9.22.0 and prior to 11.5.0, is vulnerable to asset unavailability after a burst of HEAD requests. Some tools use Directus to sync content and assets, and some of those tools use the HEAD method to check the existence of files. When making many HEAD requests at once, at some point, all assets are eventually served as 403. This causes denial of assets for all policies of Directus, including Admin and Public. Version 12.0.1 of the `@directus/storage-driver-s3` package, corresponding to version 11.5.0 of Directus, fixes the issue.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Directus is a real-time API and App dashboard for managing SQL database content. The `@directus/storage-driver-s3` package starting in version 9.22.0 and prior to version 12.0.1, corresponding to Directus starting in version 9.22.0 and prior to 11.5.0, is vulnerable to asset unavailability after a burst of HEAD requests. Some tools use Directus to sync content and assets, and some of those tools use the HEAD method to check the existence of files. When making many HEAD requests at once, at some point, all assets are eventually served as 403. This causes denial of assets for all policies of Directus, including Admin and Public. Version 12.0.1 of the `@directus/storage-driver-s3` package, corresponding to version 11.5.0 of Directus, fixes the issue.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-30350</guid>
    </item>
    <item>
      <title>GHSA-rv78-qqrq-73m5 — Directus's S3 assets become unavailable after a burst of HEAD requests</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-rv78-qqrq-73m5</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: @directus/storage-driver-s3, npm: directus&lt;/p&gt;
&lt;p&gt;### Summary
There&amp;#39;s some tools that use Directus to sync content and assets.
Some of those tools use HEAD method, like Shopify, to check the existence of files.
Although, when making many HEAD requests at once, at some point, all assets are being served as 403.&lt;/p&gt;
&lt;p&gt;### Details
When I was investigating this issue, I have found that after the burst of HEAD requests, the amount of `sockets` held on [Agent on NodeHttpHandler](https://github.com/smithy-lang/smithy-typescript/blob/main/packages/node-http-handler/src/node-http-handler.ts#L189) was always equal to [`STORAGE_CLOUD_MAX_SOCKETS`](https://github.com/directus/directus/blob/main/packages/storage-driver-s3/src/index.ts#L89) making it impossible to have new connections causing assets to be inaccessible.&lt;/p&gt;
&lt;p&gt;After looking into this [issue on AWS SDK](https://github.com/aws/aws-sdk-js-v3/issues/6691) I found that if the [stream is requested](https://github.com/directus/directus/blob/main/api/src/services/assets.ts#L213), it needs to be consumed otherwise will hang forever. And as can be [seen here](https://github.com/directus/directus/blob/main/api/src/controllers/assets.ts#L233-L238) the stream is not consumed.&lt;/p&gt;
&lt;p&gt;The [timeouts set here](https://github.com/directus/directus/blob/main/packages/storage-driver-s3/src/index.ts#L87-L88)  had no noticeable effect on tests made.&lt;/p&gt;
&lt;p&gt;### PoC
This can be easily reproduced with the following steps:
- setup AWS S3 storage
- set STORAGE_CLOUD_MAX_SOCKETS: &amp;#34;50&amp;#34; (this value is lower than default for…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: @directus/storage-driver-s3, npm: directus&lt;/p&gt;
&lt;p&gt;### Summary
There&amp;#39;s some tools that use Directus to sync content and assets.
Some of those tools use HEAD method, like Shopify, to check the existence of files.
Although, when making many HEAD requests at once, at some point, all assets are being served as 403.&lt;/p&gt;
&lt;p&gt;### Details
When I was investigating this issue, I have found that after the burst of HEAD requests, the amount of `sockets` held on [Agent on NodeHttpHandler](https://github.com/smithy-lang/smithy-typescript/blob/main/packages/node-http-handler/src/node-http-handler.ts#L189) was always equal to [`STORAGE_CLOUD_MAX_SOCKETS`](https://github.com/directus/directus/blob/main/packages/storage-driver-s3/src/index.ts#L89) making it impossible to have new connections causing assets to be inaccessible.&lt;/p&gt;
&lt;p&gt;After looking into this [issue on AWS SDK](https://github.com/aws/aws-sdk-js-v3/issues/6691) I found that if the [stream is requested](https://github.com/directus/directus/blob/main/api/src/services/assets.ts#L213), it needs to be consumed otherwise will hang forever. And as can be [seen here](https://github.com/directus/directus/blob/main/api/src/controllers/assets.ts#L233-L238) the stream is not consumed.&lt;/p&gt;
&lt;p&gt;The [timeouts set here](https://github.com/directus/directus/blob/main/packages/storage-driver-s3/src/index.ts#L87-L88)  had no noticeable effect on tests made.&lt;/p&gt;
&lt;p&gt;### PoC
This can be easily reproduced with the following steps:
- setup AWS S3 storage
- set STORAGE_CLOUD_MAX_SOCKETS: &amp;#34;50&amp;#34; (this value is lower than default for…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-rv78-qqrq-73m5</guid>
    </item>
  </channel>
</rss>
