CVE-2026-93592: vLLM before 0.28.0 Denial of Service via negative token ID

Published Sep 18, 2026
·
Updated

vLLM versions before 0.28.0 fail to validate the lower bound of token IDs in the /v1/embeddings and /pooling endpoints, allowing unauthenticated attackers to crash the engine by submitting negative token IDs. A single request with a negative token ID triggers a CUDA device-side assertion that poisons the GPU context, causing all subsequent requests to fail until the process restarts.

Affected Software

1 affected component
vllm vllm<0.28.0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade vLLM to a version that resolves this vulnerability.

    Fixed in 0.28.0
  2. Configuration

    Ensure vLLM validates the lower bound of token IDs for the /v1/embeddings and /pooling endpoints (vLLM versions before 0.28.0 did not, which allowed negative token IDs to crash the engine).

    vLLM /v1/embeddings and /pooling endpoints token_id lower-bound validation = enabled

Event History

Sep 18, 2026
CVE Published
via MITRE·01:20 PM
Data Sourced
via MITRE·01:20 PM
DescriptionSeverityWeakness

Frequently Asked Questions

1

Which deployments are exposed to unauthenticated exploitation?

Deployments running vLLM before 0.28.0 that expose the /v1/embeddings or /pooling endpoints to an attacker are exposed. The issue requires no authentication, user interaction, or special attack conditions.

2

What is the operational effect after a successful request?

A request containing a negative token ID causes a CUDA device-side assertion and poisons the GPU context. Subsequent requests fail until the affected vLLM process is restarted.

3

How can I determine whether an instance is affected?

An instance is affected if it runs a vLLM version earlier than 0.28.0 and serves the /v1/embeddings or /pooling endpoints. The described trigger is submission of a negative token ID to either endpoint.

4

What can be done if upgrading is not immediately possible?

Restrict untrusted access to the /v1/embeddings and /pooling endpoints so unauthenticated attackers cannot submit requests. If exploitation occurs, restarting the affected process is required to restore request handling after the GPU context is poisoned.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203