<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-08T00:17:57.780242+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-333525</id>
    <title>EUVD-2026-333525</title>
    <updated>2026-10-08T00:17:57.855788+00:00</updated>
    <content>EUVD-2026-333525</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-333525"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2026-55646</id>
    <title>fkie_cve-2026-55646</title>
    <updated>2026-10-08T00:17:57.855831+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>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.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2026-55646"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-v82g-2437-67m2</id>
    <title>GHSA-v82g-2437-67m2 — vLLM: Speech-to-text upload size limit is enforced after full UploadFile read</title>
    <updated>2026-10-08T00:17:57.855872+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: vllm</p>
<p>## Summary</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>## Technical Details</p>
<p>The upload routes perform an unbounded read before vLLM checks the documented compressed audio file-size limit:</p>
<p>- `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…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-v82g-2437-67m2"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/pysec-2026-2305</id>
    <title>PYSEC-2026-2305</title>
    <updated>2026-10-08T00:17:57.855935+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: vllm</p>
<p>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.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/pysec-2026-2305"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2176</id>
    <title>WID-SEC-W-2026-2176 — vllm: Mehrere Schwachstellen ermöglichen Denial of Service</title>
    <updated>2026-10-08T00:17:57.855961+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Ein Angreifer kann mehrere Schwachstellen in vllm ausnutzen, um einen Denial of Service Angriff durchzuführen.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2176"/>
  </entry>
</feed>
