vLLM: malformed IAMF audio upload reaches FFmpeg heap overflow and crashes the inference server

Impact

vLLM hands uploaded audio to the PyAV/FFmpeg av.open() fallback after only a file-size check, so a crafted IAMF container reaches a heap overflow in FFmpeg's IAMF parser. An authenticated caller of /v1/audio/transcriptions can corrupt the heap and kill the API process; repeated uploads keep it down. On a GPU node that means the model stays loaded or has to be reloaded, and every tenant sharing that endpoint loses service while weights are paged back onto the GPU. The advisory records this as a denial of service; memory corruption inside FFmpeg means code execution cannot be fully ruled out, but nothing in the record demonstrates it.

Who can reach it

Any client authenticated to the vLLM OpenAI-compatible API that can POST audio to /v1/audio/transcriptions. In a multi-tenant serving setup, that is any tenant holding an API key for the endpoint.

What to do

Upgrade vLLM to 0.29.0 or later and restart the serving process - a daemon restart with model reload, not a node reboot. Until then, disable or gate the audio transcription endpoint, and keep the FFmpeg/PyAV packages in the serving image current.

References

Related entries

• vLLM (`MediaConnector`): SSRF, recurrence of CVE-2025-6242CVE-2026-24779 · vLLM (`MediaConnector`)High
• vLLM (`load_from_url_async`): Bypass of the CVE-2026-24779 SSRF fixCVE-2026-25960 · vLLM (`load_from_url_async`)High
• picklescan: `scan_pytorch` bypass via forged magic numbersCVE-2026-53875 · picklescanHigh
• NVIDIA Megatron-LM: hash collisions in the inference cache let one request's data reach anotherCVE-2026-65104 · NVIDIA Megatron-LM (inference request cache)High
• torchvision (GIF decoder): Out-of-bounds heap read in `read_from_tensor` GIF decodeCVE-2026-65918 · torchvision (GIF decoder)High
• MLflow: model version creation reads another user's run artifacts without READ permissionCVE-2026-69148 · MLflow tracking server (CreateModelVersion source run/model validation)High