Affected: Homebrew: cycode

### 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't accept new connections.

### 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.

```python

@property def _in_memory(self) -> bool: # check for SpooledTemporaryFile._rolled rolled_to_disk = getattr(self.file, "_rolled", True) return not rolled_to_disk

async def write(self, data: bytes) -> None: if self.size is not None: self.size += len(data)

if self._in_memory: self.file.write(data) else: await run_in_threadpool(self.file.write, data) ```

I have already created a PR which fixes the problem: https://github.com/encode/starlette/pull/2962

### PoC See the discussion [here](https://github.com/encode/starlette/discussions/2927#discussioncomment-13721403) for s…

Withdrawn by the publisher.

Affected: CleanStart: litellm-database

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

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'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.

Affected: PyPI: starlette

### 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't accept new connections.

### 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.

```python

@property def _in_memory(self) -> bool: # check for SpooledTemporaryFile._rolled rolled_to_disk = getattr(self.file, "_rolled", True) return not rolled_to_disk

async def write(self, data: bytes) -> None: if self.size is not None: self.size += len(data)

if self._in_memory: self.file.write(data) else: await run_in_threadpool(self.file.write, data) ```

I have already created a PR which fixes the problem: https://github.com/encode/starlette/pull/2962

### PoC See the discussion [here](https://github.com/encode/starlette/discussions/2927#discussioncomment-13721403) for s…

python311-starlette-0.47.2-1.1 on GA media

Affected: PyPI: starlette

### 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't accept new connections.

### 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.

```python

@property def _in_memory(self) -> bool: # check for SpooledTemporaryFile._rolled rolled_to_disk = getattr(self.file, "_rolled", True) return not rolled_to_disk

async def write(self, data: bytes) -> None: if self.size is not None: self.size += len(data)

if self._in_memory: self.file.write(data) else: await run_in_threadpool(self.file.write, data) ```

I have already created a PR which fixes the problem: https://github.com/encode/starlette/pull/2962

### PoC See the discussion [here](https://github.com/encode/starlette/discussions/2927#discussioncomment-13721403) for s…

Security update for python-starlette

Affected: Ubuntu:22.04:LTS: starlette, Ubuntu:24.04:LTS: starlette, Ubuntu:25.10: starlette, Ubuntu:26.04:LTS: starlette

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'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.

Ein Angreifer kann mehrere Schwachstellen in IBM Business Automation Workflow ausnutzen, um Sicherheitsvorkehrungen zu umgehen, und um einen Denial of Service Angriff durchzuführen.