vLLM's mid-2026 problems were an authentication bypass and repeated
trust_remote_code holes (covered in
vLLM security CVEs 2026). The autumn
batch is different. Most of it is denial of service, and most of that
comes from two places: the multimodal inputs added over the last year
(audio, video, images) and the prefill/decode disaggregated serving
connectors. One bug is worse than a crash: a model can still run its
own code with trust_remote_code turned off.
The one that is not a crash
CVE-2026-90553 (CVSS 7.8, published 12
September): vLLM before 0.28.0 ignored the trust_remote_code setting
when loading the LlavaOnevision2 processor. A malicious model can ship
code in processing_llava_onevision2.py that runs with the vLLM
process's rights even when trust_remote_code is False
(GHSA-3c86-2m5g-59q7).
Same lesson as the earlier cases: the flag is a default, not a sandbox.
Only load models from sources you would run code from.
Multimodal inputs: small upload, big allocation
The common thread is that vLLM decoded attacker-supplied media before enforcing its own limits.
| CVE | What happens | Fixed in |
|---|---|---|
| CVE-2026-109311 | Audio sent to /v1/audio/transcriptions falls back to PyAV/FFmpeg with only a size check, exposing FFmpeg's IAMF parser heap overflow; repeated uploads crash the API (GHSA-m52c-39rh-f3gp) | 0.29.0 |
| CVE-2026-57173 | input_audio on /v1/chat/completions skips the duration limit, so a small compressed clip expands to a huge PCM buffer (unauthenticated) | 0.24.0 |
| CVE-2026-90555 | Forged FLAC sample-rate headers bypass the transcription duration check | 0.28.0 |
| CVE-2026-90554 | Audio extracted from video for NanoNemotronVL has no decode limits | 0.28.0 |
| CVE-2026-69147 | A request can pick the pynvvideocodec GPU video decoder even when the server was configured for a software decoder, using GPU memory the engine did not budget | 0.28.0 |
| CVE-2026-100648 | VLLM_MAX_AUDIO_CLIP_FILESIZE_MB not enforced on chat audio | 0.29.0 |
| CVE-2026-100650 | Remote or inline media fully downloaded and decoded before size and per-prompt limits apply, across four ingress paths | after 0.29.0 |
| CVE-2026-100649 | Decoder allocation limits bypassed by choosing different sampler subclasses | 0.29.0 |
If you serve a multimodal model, every one of these is reachable by whoever can call your API. Several are marked unauthenticated in their records.
Token and sampling parameters
A second group crashes or corrupts the engine from ordinary request fields:
- CVE-2026-93592 (7.5): a negative token id on
/v1/embeddingsor/poolingtriggers a CUDA device-side assertion that poisons the GPU context until restart. Fixed in 0.28.0. - CVE-2026-100654 and CVE-2026-100652: out-of-vocabulary
stop_token_idswithmin_tokensabove zero put EngineCore into a fatal state. Fixed in 0.29.0 and 0.24.0 respectively. - CVE-2026-100647: an unbounded
cache_saltvalue stalls the single scheduler thread. Fixed in 0.29.0. - CVE-2026-93840, CVE-2026-93841 and CVE-2026-93989 (low severity, but odd): token indices that pass validation corrupt the sampler state of other requests running at the same time, so one caller can change another caller's output.
Prefill/decode disaggregation
If you split prefill and decode across workers with the NIXL, Mooncake
or P2P offloading connectors, a cluster of September records (all
"through 0.29.0") applies: incomplete or crafted kv_transfer_params
crash or exhaust the decode workers
(CVE-2026-94622,
CVE-2026-94624,
CVE-2026-94626), multi-prompt requests trip
assertions or leak GPU KV cache blocks
(CVE-2026-94623,
CVE-2026-94627), and rejected requests leave
memory or transfer placeholders behind
(CVE-2026-93436,
CVE-2026-94625). The root cause is the same in
all of them: parameters meant for trusted internal coordination are
accepted from the public API.
Still open at the time of writing
Two crash bugs published on 6 October, CVE-2026-105922 (penalty handling) and CVE-2026-105775 (out-of-bounds read in the Mamba mixer), are listed as affecting vLLM up to 0.31.0, and their NVD records say the project had not responded yet. Both are rated low to medium. Watch the live list below for a fixed version.
What to do
- Upgrade to 0.30.0 or later. That clears every fixed CVE above, including those listed as "through 0.29.0" and CVE-2026-105752, a cross-tenant prefix-cache probe fixed in 0.30.0.
- Put authentication in front of the API. Set
--api-key, and still keep the server behind a proxy or private network: several records above are unauthenticated. - Turn off what you do not serve. If you do not need audio or video, do not serve a model that accepts them. If you do, keep
--limit-mm-per-prompttight. - Strip internal parameters at the edge. A reverse proxy or gateway in front of vLLM can drop
kv_transfer_paramsandmedia_io_kwargsfrom public requests. - Treat model repositories as code. Pin model revisions and only load models from publishers you trust, whatever
trust_remote_codesays.
Keep watching
The full list, refreshed from NVD every six hours, is at
vLLM CVEs. To check the tag in your
docker-compose.yml (vllm/vllm-openai:vX.Y.Z) against all of them at
once, use the stack scanner. The preview is free.