CVE-2026-73557: Race Condition in PyTorch Tensor Invariant Checks within vLLM Engine

The vulnerability CVE-2026-73557 is a race condition in vLLM, a high-throughput and memory-efficient serving engine for Large Language Models (LLMs). This flaw specifically impacts how the system handles custom prompt and multimodal embeddings (such as text, image, or audio) provided directly by the client. These features allow clients to bypass the tokenization stage by sending pre-computed serialized PyTorch tensors.\n\nThe vulnerability lies within the interaction between vLLM's concurrent, asynchronous architecture and PyTorch's process-global state model. By sending concurrent requests with custom embeddings, a remote, unauthenticated attacker can exploit this concurrency model to bypass security validation, forcing the vLLM engine to process unvalidated, malformed coordinate (COO) sparse tensors.\n\nThe vulnerability has been assigned CVE-2026-73557 and GHSA-pr7f-p5mw-fc87. It affects all versions of vLLM from 0.20.2rc0 up to, but not including, 0.26.0. Successful exploitation leads to an out-of-bounds memory write, causing a denial-of-service (DoS) crash of the vLLM serving process.

The root cause of CVE-2026-73557 is the non-thread-safe design of PyTorch's torch.sparse.check_sparse_tensor_invariants() context manager. To remediate a previous vulnerability (CVE-2025-62164), vLLM developers wrapped tensor loading calls with this context manager to enforce coordinate bounds validation on Coordinate (COO) sparse tensors.\n\nWhen PyTorch executes torch.sparse.check_sparse_tensor_invariants(), it alters a process-global validation state flag. Upon entering the context manager (__enter__), the current global validation state (usually False by default) is saved, and the process-global flag is set to True. Upon exiting the context manager (__exit__), the saved state is restored back to the process-global flag.\n\nBecause vLLM processes requests asynchronously and offloads CPU-intensive tensor deserialization tasks to a shared ThreadPoolExecutor via asyncio.gather, multiple threads can enter and exit these validation contexts concurrently. This interleaving creates a race condition. A benign thread exiting its context manager can set the global flag back to False while another concurrent thread is still inside its guarded block, leaving the remaining thread to deserialize a malicious tensor with validation silently disabled.

In the vulnerable version of vLLM, the validation context was applied directly around torch.load calls without any thread synchronization. The following code from vllm/renderers/embed_utils.py demonstrates this vulnerability:\n\npython\n# Vulnerable Implementation in vllm/renderers/embed_utils.py\nwith torch.sparse.check_sparse_tensor_invariants():\n tensor = torch.load(\n BytesIO(pybase64.b64decode(embed, validate=True)),\n weights_only=True,\n map_location=torch.device(\"cpu\"),\n )\n return tensor.to_dense()\n\n\nIn the patched version, a process-wide mutex lock _SPARSE_LOAD_LOCK is introduced in vllm/utils/sparse_utils.py to serialize all validation context manager operations. This ensures that only one thread can modify and execute within the global validation context at any given time:\n\npython\n# Patched Implementation in vllm/utils/sparse_utils.py\nimport contextlib\nimport threading\nimport torch\n\n_SPARSE_LOAD_LOCK = threading.Lock()\n\n@contextlib.contextmanager\ndef check_sparse_tensor_invariants_threadsafe():\n # Enforce mutual exclusion on the global state manipulation\n with _SPARSE_LOAD_LOCK, torch.sparse.check_sparse_tensor_invariants():\n yield\n\n\nThis synchronized wrapper is then used across all affected loader paths, including vllm/renderers/embed_utils.py, vllm/multimodal/media/audio.py, and vllm/multimodal/media/image.py, preventing concurrent interleaving.

An attacker can exploit this vulnerability by submitting a request containing both valid and malicious prompt embeddings concurrently, or by sending multiple rapid concurrent requests to the vLLM endpoint. The goal is to trigger the race condition where the exit of a benign load operation disables validation for the concurrent malicious load operation.\n\nThe malicious payload consists of a serialized PyTorch sparse COO tensor containing out-of-bounds indices. Below is an example of constructing such an invalid tensor:\n\npython\nimport io\nimport torch\nimport pybase64\n\n# Create an invalid COO sparse tensor with out-of-bounds indices\nindices = torch.tensor([[999999], [999999]])\nvalues = torch.tensor([1.0])\nshape = (5, 5)\n\ninvalid_sparse = torch.sparse_coo_tensor(\n indices, values, shape, dtype=torch.float32, check_invariants=False\n)\n\nbuf = io.BytesIO()\ntorch.save(invalid_sparse, buf)\nbuf.seek(0)\nmalicious_payload = pybase64.b64encode(buf.read()).decode(\"utf-8\")\n\n\nWhen the race condition is successfully triggered, the global validation flag is set to False before the malicious tensor calls .to_dense(). The compiled PyTorch C++ backend then attempts to write values to memory locations outside the allocated tensor buffer, leading to a segmentation fault and a denial-of-service (DoS) crash.

The exploitation of CVE-2026-73557 has a low-to-medium direct impact, primarily resulting in a Denial of Service (DoS) of the serving engine. When the invalid tensor coordinates are processed without validation, PyTorch's underlying C++ memory management routines perform out-of-bounds memory writes, causing an immediate segmentation fault (SIGSEGV) or heap corruption that terminates the vLLM daemon process.\n\nBecause vLLM serves as the primary inference backbone in production deployments, crashing the daemon disrupts LLM-powered applications and services. While there is no known vector for arbitrary code execution (ACE) or data exfiltration directly from this bug, service instability represents a significant risk for enterprise operations.\n\nThe CVSS v4.0 score is assessed at 6.3 (Medium), with a vector of CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N. The low exploitability probability (EPSS score of 0.00251) and the requirement of concurrent timing states mean that while the vulnerability is serious, widespread exploitation in the wild remains complex and low-priority.

The primary remediation for CVE-2026-73557 is upgrading to vLLM version 0.26.0 or higher. This version implements the thread-safe context manager, which completely closes the race condition window by synchronizing access to PyTorch's global validation configuration.\n\nIf an immediate upgrade is not feasible, organizations should reduce the attack surface by disabling untrusted prompt and multimodal embedding features. This can be achieved by ensuring that the vLLM server is not started with the following command-line flags:\n- --enable-prompt-embeds\n- --enable-mm-embeds\n\nAdditionally, implementing network-level protections can mitigate risk. Employing Web Application Firewalls (WAF) to inspect incoming request bodies for JSON structures containing \"type\": \"prompt_embeds\" or limiting the concurrent rate of API calls to the completion endpoints can disrupt an attacker's ability to successfully execute the race timing loop.