A medium-severity vulnerability in vLLM's Phi 4 multimodal audio encoder allowed a single max-length audio input to crash the serving engine through out-of-memory exhaustion. The fix shipped in vLLM 0.32.0; all prior versions are affected1.
The Phi 4 Multimodal Instruct audio encoder runs its conformer attention in eager mode by default because the official Hugging Face config for Microsoft's Phi 4 Multimodal Instruct does not set `use_pt_scaled_dot_product_attention`, leaving the flag at `False`. The eager path fully materializes an attention probability matrix of shape `[n_chunks, 16, 500, 500]` per layer and then stores a live reference on the module via `self.attn = attn`, a PyTorch JIT attribute declared across all 24 encoder layers.
The only server-side guards on audio length are two environment variables: `VLLM_MAX_AUDIO_CLIP_FILESIZE_MB`, defaulting to 25 MB, and `VLLM_MAX_AUDIO_DECODE_DURATION_S`, defaulting to 600 seconds. A 600-second clip, a legal input under those defaults, produces roughly 60,000 mel frames. The encoder unfolds those into 500-frame chunks, yielding approximately 120 chunks, each generating and retaining a full attention matrix across every layer.
ANALYSIS The cumulative GPU memory consumption from retaining full attention matrices across 120 chunks and 24 layers is enough to OOM-crash the vLLM engine on a single request.
The vulnerability is tracked as CVE-2026-115913 and advisory GHSA-8397-8qf6-f2gm, rated medium severity. vLLM versions below 0.32.0 are affected; version 0.32.0 is the patched release.
ANALYSIS The bug sits at the intersection of two common deployment assumptions: that upstream model configs ship with safe attention defaults, and that file-size or duration caps are sufficient input guards. Operators serving Phi 4 Multimodal Instruct through vLLM should upgrade to 0.32.0 or, where that is not immediately possible, tighten the duration and file-size environment variables well below their defaults.