Soumettre #934149: vLLM Project vLLM >=0.26.0 Denial of Service

Credit / Discovered by:
Jiapeng Li, Mingkai Yu, Junkong, Xuanhao Liu,JIajia Liu
(School of Cybersecurity, Northwestern Polytechnical University)

A vulnerability was found in vLLM 0.26.0 and later versions containing the vulnerable MoRIIO acknowledgement-retention logic. The vulnerability affects disaggregated serving deployments configured with MoRIIO in WRITE mode. It has been classified as an unauthenticated persistent resource-consumption vulnerability resulting in denial of service.

The primary vulnerability exists in the producer-side acknowledgement handling implemented in:

vllm/distributed/kv_transfer/kv_connector/v1/moriio/moriio_connector.py

MoRIIOConnectorWorker.get_finished() processes acknowledgements received from Decode nodes. If an acknowledgement contains a transfer ID that is not present in transfer_id_to_request_id, the acknowledgement is stored in _pending_unmapped_acks.

The relevant logic performs the equivalent of:

finished_acks = pending_unmapped_acks + newly_received_acks

for ack in finished_acks:
if ack.transfer_id not in transfer_id_to_request_id:
pending_unmapped_acks.append(ack)

This behavior was introduced to handle a legitimate race in which a release acknowledgement may arrive before start_load_kv() creates the transfer-ID mapping. However, acknowledgements containing transfer IDs that will never obtain a valid mapping are retained indefinitely.

The retained entries have no TTL, entry-count limit, total-byte limit, validation that the transfer ID belongs to a registered live transfer, or cleanup on request cancellation, timeout, failed handshake, or terminal transfer. The complete _pending_unmapped_acks list is merged with newly received acknowledgements and rescanned during every scheduler get_finished() tick.

The vulnerable Completion request-processing path is reachable through both /invocations and /v1/completions. The /invocations endpoint is not covered by vLLM's API-key authentication middleware, even when the service is started with --api-key, and therefore provides the unauthenticated remote attack vector. The /v1/completions endpoint reaches the same relevant Completion handling path but requires authentication when API-key protection is configured.

An attacker can submit controlled request_id and kv_transfer_params values together with stream=true and use_beam_search=true. This parameter combination causes the Completion request to return an ErrorResponse before normal engine admission.

When do_remote_prefill=true is supplied, the KV-transfer rejection-cleanup wrapper notifies the engine about the rejected request. MoRIIOConnectorScheduler.request_finished() then executes the WRITE-mode cleanup path on the Decode node and sends an internal structured release acknowledgement containing the supplied transfer ID to the Prefill node.

The attacker must know the Prefill node's notify address but does not require direct network access to the Prefill notify port. The Decode HTTP service performs the internal connection and sends the release message on the attacker's behalf.

Because the request is rejected before a corresponding producer-side transfer mapping is created, the Prefill node cannot resolve the supplied transfer ID. The resulting acknowledgement is appended to _pending_unmapped_acks and remains there permanently.

The acknowledgement ingress also permits duplicate amplification. MoRIIOWrapper._handle_release_message() appends a MoRIIOTransferAck object before marking the transfer terminal and does not reject releases for already-terminal or unknown transfer IDs. Repeated release messages using the same transfer ID may therefore create multiple retained acknowledgement objects.

If R unmatched acknowledgements are introduced during each scheduler tick for T ticks, the retained state grows as R*T. The scan performed during tick t grows as R*t, producing cumulative processing proportional to:

R*T*(T+1)/2

After malicious traffic stops, the retained state remains in memory, and every subsequent scheduler tick continues to rescan the entire unresolved acknowledgement list.

A remote unauthenticated attacker may exploit this vulnerability to cause persistent Python heap growth and continuously increasing CPU consumption in the Prefill worker. This can delay request admission and scheduling, increase time to first token, reduce inference throughput, stall the scheduler, exhaust worker memory, and ultimately make the affected vLLM service unavailable.

The initiating HTTP requests may terminate quickly, but the accumulated resource cost continues after the attack traffic has stopped. Attacker-generated entries cannot acquire a legitimate mapping and currently remain until the affected Prefill process is restarted.

This vulnerability was privately reported to the vLLM maintainers. In response, an upstream maintainer opened vLLM PR #50674 to address the persistent pending-ACK resource-exhaustion issue. At the time of submission, the pull request remained open and had not yet been merged.

The vulnerability was introduced in vLLM 0.26.0 and affects later versions that retain the vulnerable MoRIIO unmatched-ACK handling logic. The issue is not present in vLLM 0.25.0. The vulnerability has been acknowledged by the upstream project, but no fixed release was available at the time of submission.

Affected product: vLLM
Affected versions: 0.26.0 and later versions prior to the upstream fix
Affected configuration: MoRIIO WRITE-mode disaggregated serving
Affected endpoints: /invocations and /v1/completions
Unauthenticated attack endpoint: /invocations

Primary affected file:
vllm/distributed/kv_transfer/kv_connector/v1/moriio/moriio_connector.py

Related affected file:
vllm/distributed/kv_transfer/kv_connector/v1/moriio/moriio_engine.py

Affected functions:
MoRIIOConnectorScheduler.request_finished()
MoRIIOConnectorWorker.get_finished()
MoRIIOWrapper._handle_release_message()

Vulnerability class:
Persistent uncontrolled resource consumption
Improper validation of transfer acknowledgements
Missing authentication for the /invocations attack path

Suggested CWE:
CWE-400: Uncontrolled Resource Consumption

Impact:
Unauthenticated remote denial of service through persistent CPU and memory resource consumption

Fixed version:
No fixed release was available at the time of submission

• La source: ⚠️ https://github.com/vllm-project/vllm/pull/50674
• Utilisateur: JPengLi (UID 100222)
• Soumission: 17/08/2026 16:35 (il y a 1 mois)
• Modérer: 15/09/2026 20:42 (29 days later)
• Statut: Accepté
• Entrée VulDB: 404470 [vllm-project vLLM 0.26.0/0.27.0 MoRIIO Acknowledgement moriio_connector.py request_id/kv_transfer_params déni de service]
• Points: 20