GPU VulnDB

Database/AI/ML frameworks & serving

vLLM: unauthenticated video/jpeg data URL with unbounded frame count exhausts server memory

CVSS 7.5CVE-2026-5497AI/ML frameworks & servingcurated

Impact

A single OpenAI-compatible chat completions request carrying a video/jpeg data URL with thousands of comma-separated base64 JPEG frames makes vLLM decode every frame into memory with no frame count limit, crashing the server. The crash takes down the engine process, so all in-flight and queued generation on that replica is lost and the GPUs it had reserved sit idle until it is restarted. Reachable without authentication on the default API surface, so a multimodal endpoint exposed to tenants or the internet can be knocked over repeatedly by one cheap request.

Who can reach it

Anyone who can reach the vLLM OpenAI-compatible /v1/chat/completions endpoint on a build with multimodal video input enabled. No authentication required per the advisory.

What to do

Upgrade past the fix commit (58ee6142) - affects vLLM 0.8.0 and later - or pick up the Red Hat AI Inference Server, RHEL AI 3 and OpenShift AI builds that carry it, then restart each vLLM server process. Until then, reject or size-cap multimodal data URLs at the gateway in front of vLLM, or disable video input. Restart is per serving process; nodes do not need draining or rebooting.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-5497https://github.com/vllm-project/vllm/commit/58ee61422169ce17e08248f8efa1e9df434fe395https://access.redhat.com/security/cve/CVE-2026-5497https://huntr.com/bounties/7bd92629-b396-4449-8f88-6c0092530eb4

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.