<?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>Sat, 03 Oct 2026 20:41:30 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-10819</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-10819</link>
      <description>bdu:2025-10819</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-10819</guid>
    </item>
    <item>
      <title>BREW-cycode-CVE-2025-54121 — Starlette has possible denial-of-service vector when parsing large files in multipart forms</title>
      <link>https://cve.radiocsirt.org/vuln/brew-cycode-cve-2025-54121</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Homebrew: cycode&lt;/p&gt;
&lt;p&gt;### Summary
When parsing a multi-part form with large files (greater than the [default max spool size](https://github.com/encode/starlette/blob/fa5355442753f794965ae1af0f87f9fec1b9a3de/starlette/formparsers.py#L126)) `starlette` will block the main thread to roll the file over to disk. This blocks the event thread which means we can&amp;#39;t accept new connections.&lt;/p&gt;
&lt;p&gt;### Details
Please see this discussion for details: https://github.com/encode/starlette/discussions/2927#discussioncomment-13721403. In summary the following UploadFile code (copied from [here](https://github.com/encode/starlette/blob/fa5355442753f794965ae1af0f87f9fec1b9a3de/starlette/datastructures.py#L436C5-L447C14)) has a minor bug. Instead of just checking for `self._in_memory` we should also check if the additional bytes will cause a rollover.&lt;/p&gt;
&lt;p&gt;```python&lt;/p&gt;
&lt;p&gt;@property
    def _in_memory(self) -&amp;gt; bool:
        # check for SpooledTemporaryFile._rolled
        rolled_to_disk = getattr(self.file, &amp;#34;_rolled&amp;#34;, True)
        return not rolled_to_disk&lt;/p&gt;
&lt;p&gt;async def write(self, data: bytes) -&amp;gt; None:
        if self.size is not None:
            self.size += len(data)&lt;/p&gt;
&lt;p&gt;if self._in_memory:
            self.file.write(data)
        else:
            await run_in_threadpool(self.file.write, data)
```&lt;/p&gt;
&lt;p&gt;I have already created a PR which fixes the problem: https://github.com/encode/starlette/pull/2962&lt;/p&gt;
&lt;p&gt;### PoC
See the discussion [here](https://github.com/encode/starlette/discussions/2927#discussioncomment-13721403) for s…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Homebrew: cycode&lt;/p&gt;
&lt;p&gt;### Summary
When parsing a multi-part form with large files (greater than the [default max spool size](https://github.com/encode/starlette/blob/fa5355442753f794965ae1af0f87f9fec1b9a3de/starlette/formparsers.py#L126)) `starlette` will block the main thread to roll the file over to disk. This blocks the event thread which means we can&amp;#39;t accept new connections.&lt;/p&gt;
&lt;p&gt;### Details
Please see this discussion for details: https://github.com/encode/starlette/discussions/2927#discussioncomment-13721403. In summary the following UploadFile code (copied from [here](https://github.com/encode/starlette/blob/fa5355442753f794965ae1af0f87f9fec1b9a3de/starlette/datastructures.py#L436C5-L447C14)) has a minor bug. Instead of just checking for `self._in_memory` we should also check if the additional bytes will cause a rollover.&lt;/p&gt;
&lt;p&gt;```python&lt;/p&gt;
&lt;p&gt;@property
    def _in_memory(self) -&amp;gt; bool:
        # check for SpooledTemporaryFile._rolled
        rolled_to_disk = getattr(self.file, &amp;#34;_rolled&amp;#34;, True)
        return not rolled_to_disk&lt;/p&gt;
&lt;p&gt;async def write(self, data: bytes) -&amp;gt; None:
        if self.size is not None:
            self.size += len(data)&lt;/p&gt;
&lt;p&gt;if self._in_memory:
            self.file.write(data)
        else:
            await run_in_threadpool(self.file.write, data)
```&lt;/p&gt;
&lt;p&gt;I have already created a PR which fixes the problem: https://github.com/encode/starlette/pull/2962&lt;/p&gt;
&lt;p&gt;### PoC
See the discussion [here](https://github.com/encode/starlette/discussions/2927#discussioncomment-13721403) for s…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/brew-cycode-cve-2025-54121</guid>
    </item>
    <item>
      <title>certfr-2025-avi-1051 — De multiples vulnérabilités ont été découvertes dans les produits IBM. Certaines d'entre elles permettent à un attaquan…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2025-avi-1051</link>
      <description>certfr-2025-avi-1051</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2025-avi-1051</guid>
    </item>
    <item>
      <title>Withdrawn: CLEANSTART-2026-AL63130 — Security fixes in litellm-database 1.96.0-r0</title>
      <link>https://cve.radiocsirt.org/vuln/cleanstart-2026-al63130</link>
      <description>&lt;p&gt;&lt;strong&gt;Withdrawn by the publisher.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; CleanStart: litellm-database&lt;/p&gt;
&lt;p&gt;Package litellm-database version 1.96.0-r0 fixes 5 vulnerabilities: CVE-2026-54282, CVE-2025-62727, CVE-2026-48818, CVE-2026-54283, CVE-2025-54121&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Withdrawn by the publisher.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; CleanStart: litellm-database&lt;/p&gt;
&lt;p&gt;Package litellm-database version 1.96.0-r0 fixes 5 vulnerabilities: CVE-2026-54282, CVE-2025-62727, CVE-2026-48818, CVE-2026-54283, CVE-2025-54121&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cleanstart-2026-al63130</guid>
    </item>
    <item>
      <title>EUVD-2026-248246</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-248246</link>
      <description>EUVD-2026-248246</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-248246</guid>
    </item>
    <item>
      <title>fkie_cve-2025-54121</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-54121</link>
      <description>&lt;p&gt;Starlette is a lightweight ASGI (Asynchronous Server Gateway Interface) framework/toolkit, designed for building async web services in Python. In versions 0.47.1 and below, when parsing a multi-part form with large files (greater than the default max spool size) starlette will block the main thread to roll the file over to disk. This blocks the event thread which means the application can&amp;#39;t accept new connections. The UploadFile code has a minor bug where instead of just checking for self._in_memory, the logic should also check if the additional bytes will cause a rollover. The vulnerability is fixed in version 0.47.2.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Starlette is a lightweight ASGI (Asynchronous Server Gateway Interface) framework/toolkit, designed for building async web services in Python. In versions 0.47.1 and below, when parsing a multi-part form with large files (greater than the default max spool size) starlette will block the main thread to roll the file over to disk. This blocks the event thread which means the application can&amp;#39;t accept new connections. The UploadFile code has a minor bug where instead of just checking for self._in_memory, the logic should also check if the additional bytes will cause a rollover. The vulnerability is fixed in version 0.47.2.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-54121</guid>
    </item>
    <item>
      <title>GHSA-2c2j-9gv5-cj73 — Starlette has possible denial-of-service vector when parsing large files in multipart forms</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-2c2j-9gv5-cj73</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: starlette&lt;/p&gt;
&lt;p&gt;### Summary
When parsing a multi-part form with large files (greater than the [default max spool size](https://github.com/encode/starlette/blob/fa5355442753f794965ae1af0f87f9fec1b9a3de/starlette/formparsers.py#L126)) `starlette` will block the main thread to roll the file over to disk. This blocks the event thread which means we can&amp;#39;t accept new connections.&lt;/p&gt;
&lt;p&gt;### Details
Please see this discussion for details: https://github.com/encode/starlette/discussions/2927#discussioncomment-13721403. In summary the following UploadFile code (copied from [here](https://github.com/encode/starlette/blob/fa5355442753f794965ae1af0f87f9fec1b9a3de/starlette/datastructures.py#L436C5-L447C14)) has a minor bug. Instead of just checking for `self._in_memory` we should also check if the additional bytes will cause a rollover.&lt;/p&gt;
&lt;p&gt;```python&lt;/p&gt;
&lt;p&gt;@property
    def _in_memory(self) -&amp;gt; bool:
        # check for SpooledTemporaryFile._rolled
        rolled_to_disk = getattr(self.file, &amp;#34;_rolled&amp;#34;, True)
        return not rolled_to_disk&lt;/p&gt;
&lt;p&gt;async def write(self, data: bytes) -&amp;gt; None:
        if self.size is not None:
            self.size += len(data)&lt;/p&gt;
&lt;p&gt;if self._in_memory:
            self.file.write(data)
        else:
            await run_in_threadpool(self.file.write, data)
```&lt;/p&gt;
&lt;p&gt;I have already created a PR which fixes the problem: https://github.com/encode/starlette/pull/2962&lt;/p&gt;
&lt;p&gt;### PoC
See the discussion [here](https://github.com/encode/starlette/discussions/2927#discussioncomment-13721403) for s…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: starlette&lt;/p&gt;
&lt;p&gt;### Summary
When parsing a multi-part form with large files (greater than the [default max spool size](https://github.com/encode/starlette/blob/fa5355442753f794965ae1af0f87f9fec1b9a3de/starlette/formparsers.py#L126)) `starlette` will block the main thread to roll the file over to disk. This blocks the event thread which means we can&amp;#39;t accept new connections.&lt;/p&gt;
&lt;p&gt;### Details
Please see this discussion for details: https://github.com/encode/starlette/discussions/2927#discussioncomment-13721403. In summary the following UploadFile code (copied from [here](https://github.com/encode/starlette/blob/fa5355442753f794965ae1af0f87f9fec1b9a3de/starlette/datastructures.py#L436C5-L447C14)) has a minor bug. Instead of just checking for `self._in_memory` we should also check if the additional bytes will cause a rollover.&lt;/p&gt;
&lt;p&gt;```python&lt;/p&gt;
&lt;p&gt;@property
    def _in_memory(self) -&amp;gt; bool:
        # check for SpooledTemporaryFile._rolled
        rolled_to_disk = getattr(self.file, &amp;#34;_rolled&amp;#34;, True)
        return not rolled_to_disk&lt;/p&gt;
&lt;p&gt;async def write(self, data: bytes) -&amp;gt; None:
        if self.size is not None:
            self.size += len(data)&lt;/p&gt;
&lt;p&gt;if self._in_memory:
            self.file.write(data)
        else:
            await run_in_threadpool(self.file.write, data)
```&lt;/p&gt;
&lt;p&gt;I have already created a PR which fixes the problem: https://github.com/encode/starlette/pull/2962&lt;/p&gt;
&lt;p&gt;### PoC
See the discussion [here](https://github.com/encode/starlette/discussions/2927#discussioncomment-13721403) for s…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-2c2j-9gv5-cj73</guid>
    </item>
    <item>
      <title>openSUSE-SU-2025:15381-1 — python311-starlette-0.47.2-1.1 on GA media</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2025:15381-1</link>
      <description>&lt;p&gt;python311-starlette-0.47.2-1.1 on GA media&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;python311-starlette-0.47.2-1.1 on GA media&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2025:15381-1</guid>
    </item>
    <item>
      <title>PYSEC-2026-1941 — Starlette has possible denial-of-service vector when parsing large files in multipart forms</title>
      <link>https://cve.radiocsirt.org/vuln/pysec-2026-1941</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: starlette&lt;/p&gt;
&lt;p&gt;### Summary
When parsing a multi-part form with large files (greater than the [default max spool size](https://github.com/encode/starlette/blob/fa5355442753f794965ae1af0f87f9fec1b9a3de/starlette/formparsers.py#L126)) `starlette` will block the main thread to roll the file over to disk. This blocks the event thread which means we can&amp;#39;t accept new connections.&lt;/p&gt;
&lt;p&gt;### Details
Please see this discussion for details: https://github.com/encode/starlette/discussions/2927#discussioncomment-13721403. In summary the following UploadFile code (copied from [here](https://github.com/encode/starlette/blob/fa5355442753f794965ae1af0f87f9fec1b9a3de/starlette/datastructures.py#L436C5-L447C14)) has a minor bug. Instead of just checking for `self._in_memory` we should also check if the additional bytes will cause a rollover.&lt;/p&gt;
&lt;p&gt;```python&lt;/p&gt;
&lt;p&gt;@property
    def _in_memory(self) -&amp;gt; bool:
        # check for SpooledTemporaryFile._rolled
        rolled_to_disk = getattr(self.file, &amp;#34;_rolled&amp;#34;, True)
        return not rolled_to_disk&lt;/p&gt;
&lt;p&gt;async def write(self, data: bytes) -&amp;gt; None:
        if self.size is not None:
            self.size += len(data)&lt;/p&gt;
&lt;p&gt;if self._in_memory:
            self.file.write(data)
        else:
            await run_in_threadpool(self.file.write, data)
```&lt;/p&gt;
&lt;p&gt;I have already created a PR which fixes the problem: https://github.com/encode/starlette/pull/2962&lt;/p&gt;
&lt;p&gt;### PoC
See the discussion [here](https://github.com/encode/starlette/discussions/2927#discussioncomment-13721403) for s…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: starlette&lt;/p&gt;
&lt;p&gt;### Summary
When parsing a multi-part form with large files (greater than the [default max spool size](https://github.com/encode/starlette/blob/fa5355442753f794965ae1af0f87f9fec1b9a3de/starlette/formparsers.py#L126)) `starlette` will block the main thread to roll the file over to disk. This blocks the event thread which means we can&amp;#39;t accept new connections.&lt;/p&gt;
&lt;p&gt;### Details
Please see this discussion for details: https://github.com/encode/starlette/discussions/2927#discussioncomment-13721403. In summary the following UploadFile code (copied from [here](https://github.com/encode/starlette/blob/fa5355442753f794965ae1af0f87f9fec1b9a3de/starlette/datastructures.py#L436C5-L447C14)) has a minor bug. Instead of just checking for `self._in_memory` we should also check if the additional bytes will cause a rollover.&lt;/p&gt;
&lt;p&gt;```python&lt;/p&gt;
&lt;p&gt;@property
    def _in_memory(self) -&amp;gt; bool:
        # check for SpooledTemporaryFile._rolled
        rolled_to_disk = getattr(self.file, &amp;#34;_rolled&amp;#34;, True)
        return not rolled_to_disk&lt;/p&gt;
&lt;p&gt;async def write(self, data: bytes) -&amp;gt; None:
        if self.size is not None:
            self.size += len(data)&lt;/p&gt;
&lt;p&gt;if self._in_memory:
            self.file.write(data)
        else:
            await run_in_threadpool(self.file.write, data)
```&lt;/p&gt;
&lt;p&gt;I have already created a PR which fixes the problem: https://github.com/encode/starlette/pull/2962&lt;/p&gt;
&lt;p&gt;### PoC
See the discussion [here](https://github.com/encode/starlette/discussions/2927#discussioncomment-13721403) for s…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/pysec-2026-1941</guid>
    </item>
    <item>
      <title>SUSE-SU-2025:02544-1 — Security update for python-starlette</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2025:02544-1</link>
      <description>&lt;p&gt;Security update for python-starlette&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for python-starlette&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/suse-su-2025:02544-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2025-54121</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-54121</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:22.04:LTS: starlette, Ubuntu:24.04:LTS: starlette, Ubuntu:25.10: starlette, Ubuntu:26.04:LTS: starlette&lt;/p&gt;
&lt;p&gt;Starlette is a lightweight ASGI (Asynchronous Server Gateway Interface) framework/toolkit, designed for building async web services in Python. In versions 0.47.1 and below, when parsing a multi-part form with large files (greater than the default max spool size) starlette will block the main thread to roll the file over to disk. This blocks the event thread which means the application can&amp;#39;t accept new connections. The UploadFile code has a minor bug where instead of just checking for self._in_memory, the logic should also check if the additional bytes will cause a rollover. The vulnerability is fixed in version 0.47.2.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:22.04:LTS: starlette, Ubuntu:24.04:LTS: starlette, Ubuntu:25.10: starlette, Ubuntu:26.04:LTS: starlette&lt;/p&gt;
&lt;p&gt;Starlette is a lightweight ASGI (Asynchronous Server Gateway Interface) framework/toolkit, designed for building async web services in Python. In versions 0.47.1 and below, when parsing a multi-part form with large files (greater than the default max spool size) starlette will block the main thread to roll the file over to disk. This blocks the event thread which means the application can&amp;#39;t accept new connections. The UploadFile code has a minor bug where instead of just checking for self._in_memory, the logic should also check if the additional bytes will cause a rollover. The vulnerability is fixed in version 0.47.2.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-54121</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-2534 — IBM Business Automation Workflow: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2534</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in IBM Business Automation Workflow ausnutzen, um Sicherheitsvorkehrungen zu umgehen, und um einen Denial of Service Angriff durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in IBM Business Automation Workflow ausnutzen, um Sicherheitsvorkehrungen zu umgehen, und um einen Denial of Service Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2534</guid>
    </item>
  </channel>
</rss>
