Kernelclint

**Name of the Vulnerable Software and Affected Versions** vLLM versions prior to 0.30.0 **Description** In vLLM, Harmony tool continuations submitted through the "POST /v1/responses" endpoint rebuild the next-turn engine input without preserving the `cache salt` value. This causes the continuation prefix to be stored in the global unsalted cache namespace, even when the caller has enabled salting for tenant isolation. On deployments where prefix caching is enabled (the default setting), an authenticated tenant who can reconstruct a victim's low-entropy post-tool history can submit the same continuation and use the `cached tokens per turn` count to determine if the prefix was previously processed. This effectively creates a prompt-membership oracle that defeats the intended isolation of salted prefix caching. **Recommendations** Update vLLM to version 0.30.0 or later.

**Name of the Vulnerable Software and Affected Versions** vLLM versions prior to 0.28.0 **Description** A cache-mirroring desynchronization exists in the default multimodal LRU cache when `mm processor cache type` is set to `lru`. The system mirrors state between a frontend sender cache (`MultiModalProcessorSenderCache`) and an engine receiver cache (`MultiModalReceiverCache`). If a request is rejected after the frontend has rendered and hashed the multimodal input but before the engine receiver receives the payload (for example, due to a `max model len` rejection), the frontend cache incorrectly records the item as cached while the receiver cache remains empty. A subsequent request using the same `mm hash` variable will trigger a cache hit in the frontend, causing it to send no payload. This leads the receiver cache to trigger an assertion failure in the `get and update item()` function with the message "Expected a cached item," resulting in a shared-service availability failure. **Recommendations** Update vLLM to version 0.28.0 or later. As a temporary mitigation, avoid using the `lru` cache type for multimodal processing by changing the `mm processor cache type` configuration.

**Name of the Vulnerable Software and Affected Versions** vLLM versions prior to 0.30.0 **Description** In the disaggregated scale-out path, the `/inference/v1/generate` endpoint fails to validate and rebind caller-supplied multimodal state against the active model's renderer contract. This allows an authenticated attacker to submit forged data through the `features` object, specifically affecting the `kwargs data`, `mm hashes`, and `mm placeholders` fields. This flaw can lead to several critical outcomes: - Denial of Service: Forging grid geometry, field types, or providing non-positive placeholder lengths can cause an engine-fatal crash of the shared EngineCore process, resulting in a complete service outage for all tenants. - Cache Poisoning and Disclosure: Because the `mm hashes` (used as cache keys) are not bound to the actual payload, an attacker who knows or can induce a victim's content hash can poison or retrieve cross-request encoder-cache state. - Integrity Loss: Dropping sparse placeholder masks during the render-to-generate replay can alter transport semantics for models relying on these masks. **Recommendations** Update vLLM to version 0.30.0 or later. As a temporary mitigation, restrict access to the `/inference/v1/generate` endpoint to only trusted internal services to prevent unauthorized authenticated users from submitting forged multimodal payloads.

**Name of the Vulnerable Software and Affected Versions** vLLM versions prior to 0.30.0 **Description** In deployments using flash late-interaction scoring, the engine derives worker cache keys for query embeddings from the `X-Request-Id` header, which is controlled by the caller. A concurrent request that reuses a victim's identifier can overwrite the cached query embedding, causing the victim's documents to be scored against the attacker's query. Additionally, shared use counters may lead to a late-interaction cache-miss error. This issue affects the `/score` and `/rerank` endpoints. **Recommendations** Update vLLM to version 0.30.0 or later. As a temporary mitigation, restrict or sanitize the `X-Request-Id` header to prevent users from providing arbitrary values.

**Name of the Vulnerable Software and Affected Versions** vLLM versions prior to 0.30.0 **Description** vLLM is an inference and serving engine for large language models. OpenAI-compatible request models accept a `cache salt` value without enforcing the character and length restrictions required by the `IPCCacheServerKey` consumer in LMCache-MP. On deployments using the LMCache-MP connector, a salt that contains forbidden characters (such as `@`, `/`, ``, or NUL) or exceeds 128 characters can trigger an uncaught `ValueError` during scheduler cache lookup. Because the `Scheduler.schedule()` function does not wrap this call in a request-scoped exception handler, the error propagates to the `EngineCore` top-level handler, which treats any uncaught exception as fatal and terminates the entire engine process. This results in a denial of service for all concurrent users. The issue is triggered via the `cache salt` variable in request models including Completions, Chat Completions, and Responses. **Recommendations** Update vLLM to version 0.30.0 or later. As a temporary mitigation, avoid using the `cache salt` parameter in requests or ensure it does not contain the characters `@`, `/`, ``, or NUL and does not exceed 128 characters.

[Content removed]

**Name of the Vulnerable Software and Affected Versions** vLLM versions prior to 0.29.1 **Description** The server fetches and fully materializes remote or inline media before enforcing media controls, such as the `VLLM MAX AUDIO CLIP FILESIZE MB` size cap and the `--limit-mm-per-prompt` item limits. This occurs across four ingress paths: the shared media-acquisition layer `HTTPConnection.get bytes()`/`async get bytes()`, the chat completions `audio url`/`base64` path, the batch speech runner, and the Rust frontend `POST /tokenize` route. Because the server reads the entire HTTP response body or base64-decodes the payload before applying limits, a remote attacker can cause memory allocation and outbound bandwidth consumption proportional to the chosen body size or media item count. This leads to pre-inference memory and bandwidth exhaustion, resulting in a denial of service. While chat and batch surfaces may require an API key, the `POST /tokenize` route is unauthenticated. **Recommendations** Update to a version later than 0.29.0. Restrict access to the `POST /tokenize` route to minimize the risk of unauthenticated exploitation.

**Name of the Vulnerable Software and Affected Versions** vLLM versions 0.22.1 through 0.27.9 **Description** A supply-chain integrity and reproducibility issue exists where the model revision pin provided via `--revision` or `--code-revision` is not propagated to specific Hugging Face artifact loads for FunAudioChat and Tarsier2 architectures. Specifically, this affects the `WhisperFeatureExtractor` and `speech tokenizer` `PreTrainedTokenizerFast` loads in `vllm/model executor/models/funaudiochat.py`, as well as the `Qwen2VLConfig.from pretrained()` function used by `Tarsier2ProcessingInfo` in `vllm/model executor/models/qwen2 vl.py`. Consequently, deployments pinned to a specific revision may still load processor, tokenizer, and configuration artifacts from the repository's default revision, allowing upstream changes to the default branch to alter audio preprocessing, speech tokenizer behavior, or Tarsier2 configuration without the operator's knowledge. **Recommendations** Update vLLM to version 0.28.0.