vllm-project/vllm vulnerabilities
4 known vulnerabilities in vllm-project/vllm from Vllm-project. 4 are rated high or critical. Each entry lists the affected versions and the release that fixes it, where the vendor has published one.
Latest first
- 7.5 High severity
vllm-project/vllm: Uncontrolled Resource Consumption
vLLM versions 0.8.0 and later are vulnerable to an Out-of-Memory (OOM) Denial of Service (DoS) attack due to unbounded frame count processing in the `VideoMediaIO.load_base64()` method. When processing `video/jpeg` data URLs, the method splits the base64 data
- 8.8 High severity
vllm-project/vllm: Improper Limitation of a Pathname to a Restricted Directory
vllm-project/vllm version 0.14.1 contains a vulnerability where the `trust_remote_code=True` parameter is hardcoded in two model implementation files (`vllm/model_executor/models/nemotron_vl.py` and `vllm/model_executor/models/kimi_k25.py`). This bypasses the
- 9.8 Critical severity
vllm-project/vllm: Improper Neutralization of Special Elements used in an OS Command
vllm-project vllm version 0.6.0 contains a vulnerability in the AsyncEngineRPCServer() RPC server entrypoints. The core functionality run_server_loop() calls the function _make_handler_coro(), which directly uses cloudpickle.loads() on received messages withou
- 9.8 Critical severity
vllm-project/vllm: Deserialization of Untrusted Data
vllm-project vllm version v0.6.2 contains a vulnerability in the MessageQueue.dequeue() API function. The function uses pickle.loads to parse received sockets directly, leading to a remote code execution vulnerability. An attacker can exploit this by sending a