<?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>Wed, 07 Oct 2026 20:59:12 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-55646 — vLLM speech-to-text endpoints allocate full upload before enforcing the audio file-size limit</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2026-55646</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; vllm-project vllm&lt;/p&gt;
&lt;p&gt;vLLM is an inference and serving engine for large language models. From 0.22.0 to 0.23.0, the /v1/audio/transcriptions and /v1/audio/translations routes call request.file.read() to fully materialize an uploaded audio file into memory before vLLM checks the documented VLLM_MAX_AUDIO_CLIP_FILESIZE_MB compressed upload size limit (default 25 MB) later in the speech-to-text preprocessing step, so an API caller who can reach those routes can submit an oversized multipart upload and cause vLLM to allocate memory proportional to the uploaded file size before the request is rejected as too large, creating memory pressure or terminating the process depending on deployment resource limits. This issue is fixed in version 0.24.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; vllm-project vllm&lt;/p&gt;
&lt;p&gt;vLLM is an inference and serving engine for large language models. From 0.22.0 to 0.23.0, the /v1/audio/transcriptions and /v1/audio/translations routes call request.file.read() to fully materialize an uploaded audio file into memory before vLLM checks the documented VLLM_MAX_AUDIO_CLIP_FILESIZE_MB compressed upload size limit (default 25 MB) later in the speech-to-text preprocessing step, so an API caller who can reach those routes can submit an oversized multipart upload and cause vLLM to allocate memory proportional to the uploaded file size before the request is rejected as too large, creating memory pressure or terminating the process depending on deployment resource limits. This issue is fixed in version 0.24.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2026-55646</guid>
    </item>
    <item>
      <title>GHSA-v82g-2437-67m2 — vLLM: Speech-to-text upload size limit is enforced after full UploadFile read</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-v82g-2437-67m2</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: vllm&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;Current-head vLLM documents `VLLM_MAX_AUDIO_CLIP_FILESIZE_MB` as the maximum audio file size accepted by the speech-to-text APIs. The default is 25 MB. `vllm/envs.py` also describes files larger than this value as rejected.&lt;/p&gt;
&lt;p&gt;The `/v1/audio/transcriptions` and `/v1/audio/translations` routes call `await request.file.read()` before vLLM checks that limit. In FastAPI and Starlette, `UploadFile.read()` returns bytes from the uploaded file object; when called without a size argument, the route materializes the remaining file contents. vLLM then performs the compressed file-size check later in `_preprocess_speech_to_text()` against the already-created `bytes` object.&lt;/p&gt;
&lt;p&gt;As a result, the documented compressed audio file-size limit does not bound the memory allocated by vLLM endpoint code before validation. An oversized multipart upload can cause vLLM to allocate memory proportional to the uploaded file size before rejecting the request as too large.&lt;/p&gt;
&lt;p&gt;This is distinct from `GHSA-6pr9-rp53-2pmc`, which covered decoded PCM expansion after compressed input was accepted. This report covers compressed upload materialization before compressed-size validation.&lt;/p&gt;
&lt;p&gt;## Technical Details&lt;/p&gt;
&lt;p&gt;The upload routes perform an unbounded read before vLLM checks the documented compressed audio file-size limit:&lt;/p&gt;
&lt;p&gt;- `vllm/entrypoints/speech_to_text/transcription/api_router.py`: `audio_data = await request.file.read()`
- `vllm/entrypoints/speech_to_text/translation/api_router.py`: `audio_data = await…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: vllm&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;Current-head vLLM documents `VLLM_MAX_AUDIO_CLIP_FILESIZE_MB` as the maximum audio file size accepted by the speech-to-text APIs. The default is 25 MB. `vllm/envs.py` also describes files larger than this value as rejected.&lt;/p&gt;
&lt;p&gt;The `/v1/audio/transcriptions` and `/v1/audio/translations` routes call `await request.file.read()` before vLLM checks that limit. In FastAPI and Starlette, `UploadFile.read()` returns bytes from the uploaded file object; when called without a size argument, the route materializes the remaining file contents. vLLM then performs the compressed file-size check later in `_preprocess_speech_to_text()` against the already-created `bytes` object.&lt;/p&gt;
&lt;p&gt;As a result, the documented compressed audio file-size limit does not bound the memory allocated by vLLM endpoint code before validation. An oversized multipart upload can cause vLLM to allocate memory proportional to the uploaded file size before rejecting the request as too large.&lt;/p&gt;
&lt;p&gt;This is distinct from `GHSA-6pr9-rp53-2pmc`, which covered decoded PCM expansion after compressed input was accepted. This report covers compressed upload materialization before compressed-size validation.&lt;/p&gt;
&lt;p&gt;## Technical Details&lt;/p&gt;
&lt;p&gt;The upload routes perform an unbounded read before vLLM checks the documented compressed audio file-size limit:&lt;/p&gt;
&lt;p&gt;- `vllm/entrypoints/speech_to_text/transcription/api_router.py`: `audio_data = await request.file.read()`
- `vllm/entrypoints/speech_to_text/translation/api_router.py`: `audio_data = await…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-v82g-2437-67m2</guid>
    </item>
  </channel>
</rss>
