One negative token ID can stop an exposed vLLM embedding server

A single unauthenticated request can terminate a vulnerable vLLM process when an embedding or pooling client supplies a negative token ID. The project’s security advisory says -1 is sufficient: the request receives an HTTP 500 response, the health endpoint then refuses connections, and the process must be restarted.

What fails

The affected /v1/embeddings and /pooling paths accept token IDs directly. vLLM checked whether an ID exceeded the vocabulary’s upper bound, but did not reject values below zero. A negative value therefore reached the GPU embedding-table lookup and triggered a CUDA device-side assertion.

That failure poisons the CUDA context rather than producing a recoverable Python indexing exception. According to the advisory, subsequent CUDA work in the same process fails, including requests unrelated to the malicious input. The impact is availability only; the project reports no confidentiality or integrity loss.

The issue is especially sharp at the service boundary because it requires no authentication, unusual payload size or request sequence. Restarting the server under a supervisor is not a sufficient defense: the same request can be repeated as soon as the process returns.

Who needs to act

Operators should treat internet-facing or otherwise untrusted embedding and pooling endpoints as exposed. The project verified the failure against an unpatched vLLM 0.27.1 image and verified the corrected behavior in 0.28.0.

vLLM 0.28.0 adds a lower-bound check before token IDs reach the device. Negative IDs now receive an HTTP 400 response, while the engine and health endpoint remain available. The validation path is shared across generation, embedding and pooling requests.

What to do

Upgrade affected deployments to vLLM 0.28.0 or later. Where an immediate upgrade is not possible, the advisory recommends rejecting negative integers in input at a reverse proxy or API gateway, accepting only string input from untrusted callers, or restricting network access to the two affected endpoints.

The ordinary completions endpoint is not affected because its request schema already constrains token IDs to non-negative values. The score and rerank endpoints do not accept token-ID input in this form.