Skip to content
Heist/ feed
Back to feed
Medium

vLLM speech-to-text endpoints allocate full upload before enforcing the audio file-size limit

Type: advisorySources: OSV

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.

Products
Not specified
Affected versions
Not specified
Fixed versions
Not specified
CVEs
CVE-2026-55646
Confirmed fixed CVEs
Not specified
Updated in this feed
4 Nov 2026, 17:32 UTC · Revision 1

Source evidence

vLLM speech-to-text endpoints allocate full upload before enforcing the audio file-size limit

core-osv · Original source

Published 6 Jul 2026, 19:41 UTC

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.

osv:CVE-2026-55646
Complete source record
{
  "id": "88b63f3e2587929a287dabfcdbb6d9abc16a969135d96f909d33bab93a8c0107",
  "url": "https://osv.dev/vulnerability/CVE-2026-55646",
  "method": "structured",
  "payload": {
    "kind": "advisory",
    "title": "vLLM speech-to-text endpoints allocate full upload before enforcing the audio file-size limit",
    "summary": "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.",
    "evidence": "osv:CVE-2026-55646",
    "products": [],
    "severity": "medium",
    "structured": {
      "id": "CVE-2026-55646",
      "aliases": [
        "CVE-2026-55646",
        "GHSA-v82g-2437-67m2",
        "PYSEC-2026-2305"
      ],
      "metrics": [
        {
          "type": "CVSS_V3",
          "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"
        }
      ],
      "affected": [
        {
          "ranges": [
            {
              "repo": "https://github.com/vllm-project/vllm",
              "type": "GIT",
              "events": [
                {
                  "introduced": "0b3ba88f165976e77ca5e6a7a3f5bba4562b80af"
                },
                {
                  "fixed": "217c64a976869883fcf0c52a8cf8bc3c954d285b"
                },
                {
                  "fixed": "b997071ec493765abbed990c65843ed05e4708a8"
                }
              ],
              "database_specific": {
                "extracted_events": [
                  {
                    "cpe": "cpe:2.3:a:vllm:vllm:*:*:*:*:*:*:*:*",
                    "range": [
                      {
                        "introduced": "0.22.0"
                      },
                      {
                        "fixed": "0.24.0"
                      }
                    ],
                    "source": "CPE_RANGE"
                  },
                  {
                    "range": [
                      {
                        "fixed": "b997071ec493765abbed990c65843ed05e4708a8"
                      }
                    ],
                    "source": "REFERENCES_COMMIT"
                  }
                ]
              }
            }
          ],
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-55646.json"
          }
        }
      ],
      "modified": "2026-10-28T02:30:37.791831380Z",
      "provider": "osv",
      "references": [
        "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/55xxx/CVE-2026-55646.json",
        "https://github.com/vllm-project/vllm/security/advisories/GHSA-v82g-2437-67m2",
        "https://nvd.nist.gov/vuln/detail/CVE-2026-55646",
        "https://github.com/vllm-project/vllm/commit/b997071ec493765abbed990c65843ed05e4708a8",
        "https://github.com/vllm-project/vllm/pull/45510"
      ],
      "provider_metadata": {
        "cwe_ids": [
          "CWE-400",
          "CWE-770"
        ],
        "cna_assigner": "GitHub_M",
        "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/55xxx/CVE-2026-55646.json"
      }
    },
    "related_cves": [
      {
        "value": "CVE-2026-55646",
        "evidence": "/id"
      }
    ],
    "security_relevant": true,
    "severity_evidence": "/severity/0/score"
  },
  "source_id": "core-osv",
  "document_id": 505345,
  "published_at": "2026-07-06T19:41:11.33+00:00"
}