Tornado HTTP servers prior to version 6.6 are vulnerable to event loop blocking and excessive memory use when processing HTTP/1.1 chunked transfer encoded bodies composed of many small chunks. An attacker can send a request body with millions of 1-byte chunks, causing the server's event loop to block for extended periods (up to a minute for bodies near 100 MB), impacting all connections served by the process. This vulnerability also affects Tornado's SimpleAsyncHTTPClient when reading responses from malicious servers. The issue is fixed in Tornado 6.6, which introduces periodic yielding to the event loop and more efficient chunk handling.
Tornado's RedirectHandler prior to version 6.6 allows crafted requests to cause open redirects via protocol-relative URLs or substitutions that alter the scheme or host in the redirect URL. This occurs when URL templates use regex capture groups that influence the scheme or host, enabling attackers to redirect users to arbitrary external sites. The vulnerability is fixed in Tornado 6.6, which rejects such substitutions with a 400 error.
Tornado HTTP servers have a vulnerability in their HTTP header parser that causes quadratic CPU usage when parsing headers with obsolete line folding (line continuation with leading whitespace). This can be exploited by unauthenticated attackers sending specially crafted requests with many short continuation lines, leading to significant CPU consumption and blocking the event loop. The issue affects all Tornado versions prior to 6.6. The vulnerability impacts availability only and has been fixed in Tornado 6.6 by rejecting headers with leading whitespace. Mitigations include keeping the max_header_size at default or lower and using a reverse proxy to normalize or reject such headers.
Electrum versions prior to 4.8.3 are vulnerable to a malicious server attack where the server can replace a just-broadcast transaction with a conflicting transaction containing the attacker's output address. This attack exploits the client's trust in the server's mempool data and the lack of signature verification for unconfirmed transactions, potentially tricking users into fee-bumping a fraudulent transaction and losing funds. The issue is fixed in Electrum 4.8.3 by verifying signatures of wallet-owned inputs in mempool transactions before adding them to the local history.
A vulnerability in mem0ai's session key construction allows cross-tenant data leakage and corruption. The function _build_session_scope() concatenates user_id, agent_id, and run_id with unescaped '&' and '=' delimiters, enabling an attacker controlling only run_id or agent_id to craft values that collide with another tenant's session key. This leads to unauthorized reading and overwriting of another tenant's conversation history. The flaw affects both Python and TypeScript SDKs and is fixed in versions 2.0.18 and 3.1.6.
The Python Social Auth library's OpenID Connect backend does not bind the nonce to the user's browser session. This allows an attacker who steals an unused authorization code to redeem it in their own browser, effectively logging in as the victim. The vulnerability arises because the nonce is stored globally in a shared association table and validated only for existence and expiration, not for session ownership. The default configuration disables PKCE, which would otherwise prevent this attack. A fix is available in version 6.2.0.
A vulnerability in ONNX ConvTranspose shape inference causes an out-of-bounds read when the weight tensor has fewer than three dimensions and no kernel_shape attribute is provided. This leads to a process crash (denial of service) during shape inference on a crafted model. The issue affects ONNX versions 1.2.1 through 1.21.0 and is fixed in version 1.22.0. No confidentiality or integrity impact is reported.
ONNX versions prior to 1.22.0 contain a vulnerability in their Python tensor-materialization helpers where packed sub-byte tensors are expanded without verifying that the payload contains the declared number of elements. This can cause excessive memory allocation when processing maliciously crafted models, leading to denial of service via memory exhaustion. The issue affects specific tensor types stored in raw_data or packed int32_data. The vulnerability is fixed in ONNX 1.22.0 and later.
A vulnerability in ONNX shape inference (versions 1.4.0 through 1.21.0) allows denial of service via null pointer dereference or excessive allocation caused by improper validation of the required Scan attribute 'num_scan_inputs'. This can cause application termination or exceptions when processing malformed models. The issue is fixed in ONNX 1.22.0.
ONNX versions through 1.21.0 have a vulnerability in shape inference for RNN, GRU, and LSTM nodes from opsets 1–6 where an out-of-bounds read occurs if the first input's rank is not three. This can cause a process using onnx.shape_inference.infer_shapes() to crash, resulting in denial of service. The issue is fixed in ONNX 1.22.0 by validating the input rank before accessing dimensions.
vLLM versions prior to 0.32.0 have a permissive default CORS configuration allowing any origin to send cross-origin requests to the HTTP server. Without an API key configured, no authentication is enforced, enabling malicious web pages to access and interact with the server if reachable by the victim's browser. This can lead to unauthorized enumeration of models and execution of chat completions, potentially consuming GPU resources and exposing model outputs. The issue is fixed in version 0.32.0.
The Phi-4 multimodal audio encoder in vLLM versions prior to 0.32.0 runs its conformer attention in eager mode by default, which fully materializes and retains large attention matrices per layer during audio processing. This causes GPU memory to grow monotonically within a single request, leading to out-of-memory errors and a crash of the entire server when processing a 10-minute audio clip. The retained attention matrices persist beyond request completion, causing sustained high memory usage. This vulnerability allows any unauthenticated client with API access to cause a full denial of service with a single legal audio request.
vLLM deployments serving DeepSeek-OCR family models are vulnerable to a denial of service caused by a crafted PNG image. A legitimate half-black/half-white 1024×1024 image triggers a zero-sum pixel value condition that causes the model's input validation to return None. This leads to an assertion failure in the engine worker process, crashing the entire service and requiring manual restart. The issue affects versions from 0.11.1 up to but not including 0.32.0 and is fixed in version 0.32.0.
vLLM version prior to 0.32.0 contains a vulnerability where untrusted image bytes can be passed to Pillow's format autodetection without restriction, allowing an EPS image payload to reach the Ghostscript executable on the host. If the host's Ghostscript is vulnerable to CVE-2024-29510, this can lead to remote code execution with the privileges of the vLLM process. Additionally, certain Pillow versions (12.0.0–12.2.0) can be triggered into a denial-of-service condition by crafted EPS inputs. The issue is fixed in vLLM 0.32.0.
vLLM versions prior to 0.32.0 contain a vulnerability in their multimodal shared memory (SHM) cache handling. When the --mm-processor-cache-type shm option is enabled, an authenticated user can supply crafted SHM handles that the worker process dereferences without proper authentication, leading to deserialization of attacker-controlled data via pickle.loads(). This flaw is exploitable through public HTTP routes without requiring insecure serialization flags. The issue is fixed in version 0.32.0.
vLLM versions prior to 0.32.0 contain a vulnerability where an out-of-vocabulary token ID equal to the vocabulary size can bypass input validation and cause a CUDA device-side assert, crashing the engine. This affects models whose vocabulary size is an exact multiple of the embedding padding size (64), such as Llama-2-family models with a vocab size of 32000. The issue occurs specifically when using a single GPU (tensor parallel size 1) configuration. The flaw was fixed in vLLM version 0.32.0 by correcting the maximum accepted token ID validation.
vLLM versions from 0.16.0 up to but not including 0.32.0 have a vulnerability in the /v1/responses API endpoint where the request-level chat_template_kwargs parameter bypasses the trust_request_chat_template security gate. This allows an authenticated user to supply a malicious Jinja chat template despite the trust flag being disabled, potentially causing CPU and memory exhaustion. The issue was fixed in version 0.32.0.
vLLM versions 0.19.0 through 0.31.x have a denial-of-service vulnerability in their chat template rendering. The issue arises because the Jinja2 rendering in a sandboxed environment lacks execution timeouts and output limits, and runs in a single-threaded pool that cannot be interrupted. An authenticated attacker can submit a crafted template that exhausts the renderer thread pool or causes out-of-memory conditions, permanently denying chat-style API endpoints until the process is restarted. This affects all tenants on the same API-server replica and can also be triggered by malicious model repositories with hostile templates. The vulnerability is fixed in version 0.32.0.
The langgraph-cli versions 0.4.15 through 0.4.31 have a vulnerability where the temporary registry push token used for Docker login is printed in the output of the `langgraph deploy --verbose` command. This token could be exposed in CI logs or terminal recordings, allowing unauthorized users to push and pull images from the deployment's image repository until the token expires (up to 12 hours). The issue is fixed in version 0.4.32 and later, which suppresses token printing during verbose output.
The Autobahn Python library's permessage-brotli extension inflates entire frames before enforcing the maxMessagePayloadSize limit, allowing a small compressed frame to cause excessive memory allocation. This can lead to a denial-of-service (DoS) condition by exhausting server memory. The issue affects versions from 26.7.1 up to but not including 26.10.1 and was fixed in version 26.10.1.