Dhalf

**اسم البرنامج المصاب والإصدارات المتأثرة** vLLM الإصدارات السابقة لـ 0.29.0 **Description** يقوم البرنامج بتمرير الملفات الصوتية المرفوعة إلى نظام التراجع `av.open()` الخاص بـ PyAV/FFmpeg مع إجراء فحص لحجم الملف فقط، مما يعرض نظام تحليل IAMF في FFmpeg لثغرة تجاوز سعة ذاكرة التراكم (heap overflow). يمكن للمهاجمين عن بُعد المصرح لهم استغلال ذلك عن طريق رفع حاويات IAMF مشوهة بشكل متكرر إلى نقطة النهاية '/v1/audio/transcriptions'، مما يؤدي إلى تلف ذاكرة التراكم وتعطل عملية واجهة برمجة التطبيقات (API). **Recommendations** تحديث vLLM إلى الإصدار 0.29.0 أو إصدار أحدث.

**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 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** 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.

[Content removed]

**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.

**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.