GPU VulnDB

Database/AI/ML frameworks & serving

vLLM: request-selected video decoder backend allocates GPU memory outside the KV-cache budget

CVSS 6.5CVE-2026-69147AI/ML frameworks & servingcurated

Impact

A request body for Chat Completions or Responses can set media_io_kwargs.video.video_backend to pynvvideocodec, and MediaConnector.fetch_video honours that choice even when the server was started with a software decoder. The engine only reserves decoder memory from static startup configuration, so the request-chosen backend creates a CUDA context, decoder surfaces and decoded-frame allocations that were never subtracted from the KV-cache budget. On a video-capable deployment with PyNvVideoCodec installed, a caller can drive GPU memory to exhaustion, producing request failures, worker crashes and denial of service. On a shared inference node that takes out every model replica pinned to the affected GPUs, not just the abusive tenant's traffic.

Who can reach it

Any authenticated client that can submit video requests to a video-capable vLLM endpoint with PyNvVideoCodec installed. No privileged access and no unusual server configuration beyond enabling video input.

What to do

Upgrade to vLLM 0.28.0 or later and restart the serving processes; a rolling restart per replica is enough, no node reboot. Until then, the exposure can be reduced by not installing PyNvVideoCodec in the serving image or by rejecting client-supplied media_io_kwargs at the gateway.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-69147https://github.com/vllm-project/vllm/security/advisories/GHSA-8pw2-6jv3-mj5jhttps://github.com/vllm-project/vllm/pull/47259https://github.com/vllm-project/vllm/commit/283893c72292ede38d277e3cd2b9b64c3e4f1dda

Related entries

All AI/ML frameworks & serving entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.