CVE-2026-73558: vLLM: Cross-User Data Leak Vulnerability

The kernel computes memory offsets with 32-bit arithmetic, for example blockIdx.x * 2 * d. When the token count and hidden size are large enough, the offset wraps. Where 2^32 is divisible by d, a later token reads the activations of an earlier one. The result is that one request's computation consumes another request's data.

The reporters reproduced it on meta-llama/Llama-3.2-1B-Instruct (d = 8192) with a batch of 17 requests of 16,384 tokens. The last response became an exact copy of the first. An attacker who can send long requests that land in the same batch as a victim's can have the victim's output copied into their own response.

This matters on shared vLLM endpoints serving several tenants or users. It does not affect a single-user setup. The CVSS vector marks the attack complexity as high, because the attacker must produce a batch of the right shape alongside the victim's request.

All vLLM releases before 0.27.0. In 0.21.0 and earlier, the flawed code is in csrc/activation_kernels.cu. In later releases it is in csrc/libtorch_stable/activation_kernels.cu. The fix pull request changes act_and_mul_kernel, act_and_mul_kernel_with_param and activation_kernel.

pip show vllm

Shared, multi-user deployments that accept long prompts are the exposed case.

Upgrade to 0.27.0.

pip install --upgrade vllm

The fix in pull request 49660 computes the token index as int64_t so the pointer offsets use 64-bit arithmetic. Normal workloads keep their existing behavior. The advisory gives no workaround. Until you can upgrade, capping the maximum batched tokens and prompt length on shared endpoints is a reasonable precaution, but no source recommends it.

The sources give no log signature. The leak shows up in output, not in logs. Compare responses in a batch for duplicated or partial text that does not match the prompt, especially from requests with very long inputs. Review request logs for unusually long prompts, near 16k tokens, sent in bursts from one client.

Summary

An integer overflow in the act_and_mul_kernel kernel can cause the output of one user request to be incorporated into the response of another request within the same inference batch. Under certain conditions, the last request in a batch can receive a partial or complete copy of the first user's inference result, resulting in cross-user data leakage.

Details

The root cause is an integer overflow in the expression blockIdx.x * 2 * d at https://github.com/vllm-project/vllm/blob/ff712f6447093d07747c88680b9d006b119f5890/csrc/activation_kernels.cu#L82.

As a result, the computation for one user (User A) can incorrectly consume input data from another user (User B). In particular, when 2^32 is divisible by d, the overflow can cause User A's output to contain portions of User B's inference result. In some cases, User B's response may be copied entirely into User A's response.

This constitutes a severe cross-user information disclosure vulnerability and is straightforward to trigger.

PoC

We reproduced the issue using meta-llama/Llama-3.2-1B-Instruct, for which d = 8192.

Using the following configuration:

Batch size: 17 Sequence length: 16384

The final response in the batch becomes an exact copy of the first response in the batch, demonstrating complete cross-user data leakage.

Impact

This vulnerability enables cross-user information disclosure. An attacker can intentionally craft requests that are processed within the same inference batch as a victim's request and cause the victim's inference output to be copied into the attacker's response.

As a result, sensitive information contained in another user's model response may be exposed to an unauthorized party.

Versions

For versions prior and equal to 0.21.0, the bug is in csrc/activation_kernels.cu, and for versions later than 0.21.0, the bug is in csrc/libtorch_stable/activation_kernels.cu.