{"schema":"threatline.record/2","record":{"id":"GHSA-4m6g-h9mv-wqjc","aliases":["GHSA-4m6g-h9mv-wqjc"],"summary":"Frame-count cap bypass in VideoMediaIO.load_base64 for video/jpeg via media_io_kwargs.video.num_frames","details":"## Summary\n\nThe frame-count protection for inline `video/jpeg` data could be bypassed by overriding `VideoMediaIO.num_frames` through request-level `media_io_kwargs`. Setting `num_frames` to `-1` selects the unlimited branch, which splits and decodes every frame. A large inline video can therefore make the API frontend allocate a multi-gigabyte frame array before later request validation rejects it.\n\nThe report confirmed this on vLLM 0.19.1. Runtime `media_io_kwargs` support first shipped in stable v0.18.0.\n\n## Affected code\n\nFor `video/jpeg`, `VideoMediaIO.load_base64` limits frames when `num_frames` is positive, rejects zero, and otherwise splits the full input. The request's `media_io_kwargs.video` values were passed to `VideoMediaIO` without restricting `num_frames`, allowing a client override of `-1` or an arbitrarily large positive value.\n\nThe decoded JPEG frames are individually loaded and then combined with `numpy.stack`, so an oversized request can consume substantial API-server memory before the engine processes it.\n\n## Impact\n\nA client able to call the chat endpoint could submit a large inline `video/jpeg` payload and cause excessive memory and CPU use in the API frontend. The reported deployment used a video-capable multimodal model. The issue could crash or OOM-kill the serving process.\n\n## Fix\n\nPR #58830 rejects non-empty per-request `media_io_kwargs` by default, preventing clients from overriding the server's video decoder settings. Deployments that explicitly trust their API clients can opt in with `--trust-request-mm-kwargs`.\n","categories":["Unclassified"],"product":"vllm","vendor":"","ecosystem":null,"affected_ranges":[{"source":"GitHub Advisory Database","source_url":"https://github.com/vllm-project/vllm/security/advisories/GHSA-4m6g-h9mv-wqjc","source_modified_at":"2026-10-09T08:24:22Z","fetched_at":"2026-10-27T04:51:10.072820Z","package":{"ecosystem":"pip","name":"vllm"},"range":">= 0.18.0, < 0.31.0"}],"fixed_versions":[],"cvss":null,"severity":"High","kev":{"listed":false},"epss":{"probability":null,"percentile":null,"score_date":null},"published_at":"2026-10-09T08:24:22Z","modified_at":"2026-10-09T08:24:22Z","provenance":[{"source":"GitHub Advisory Database","url":"https://github.com/vllm-project/vllm/security/advisories/GHSA-4m6g-h9mv-wqjc","fetched_at":"2026-10-27T04:51:10.072820Z","source_modified_at":"2026-10-09T08:24:22Z"}],"sources":["GitHub Advisory Database"],"references":[],"locations":[],"motoko_assessment":{"status":"requires_architecture_review","automatic_remediation":false},"classification":{"method":"product-first software-layer rules","rules_version":"2.1","matched_on":null,"confidence":"unknown","reviewed":false},"change_timestamp":"2026-10-09T08:24:22Z","content_hash":"dbdc4f24186e9cc1278e1f9d8d6f8bc8b40f2e94319fce8ef0ef0c37ed26aa16"}}