Summary

When the OffloadingConnector uses TieringOffloadingSpec with a P2P secondary tier, an API client can submit many unique non-listening peer addresses through kvtransferparams.prefill. vLLM keeps every never-established P2P session and its ZeroMQ sockets after the request finishes. On vLLM 0.26.0, 340 such peers filled the default ZeroMQ context socket quota; creating the next peer raised an uncaught ZMQError, terminated EngineCore, and shut down the API server. The path was reproduced with a normal API key and no access to the internal P2P listener.

Details

Root cause

In vLLM 0.26.0, P2PSecondaryTierManager.onnewrequest() reads the following request-controlled fields:

json { "kvtransferparams": { "prefill": { "kvrequestid": "id", "remotehost": "127.0.0.1", "remoteport": 49101 } } }

onnewrequest() calls getorcreatesession(peerid). This calls ZmqTransport.connect(), creates a P2PSession, and stores it in sessions before the asynchronous ZeroMQ connection has been established.

ZmqTransport.openconnection() creates a DEALER, enables a libzmq monitor, creates a PAIR socket for that monitor, calls dealer.connect(), and immediately stores the resulting ZmqConnection in connections. Returning from dealer.connect() does not prove that the peer is reachable.

The monitor subscribes only to zmq.EVENTDISCONNECTED. A peer that never accepts the initial connection produced EVENTCONNECTDELAYED, EVENTCONNECTRETRIED, and EVENTCLOSED, but no EVENTDISCONNECTED during a 60-second observation. The production monitor therefore never calls markdead(), and ZmqConnection.alive remains true.

Request completion calls session.finishrequest(), but does not close or remove the peer session. The manager reaps only a session for which session.connected and not session.alive is true. A never-established peer remains connected=True, alive=True, and ready=False. There is no establishment deadline, idle eviction, or limit on pending or total peers.

Each unique retained peer uses about three sockets in the same ZeroMQ context: the DEALER, the monitor endpoint created by libzmq, and the PAIR monitor client. With the measured default MAXSOCKETS=1023, 340 peers use approximately 1,020 sockets in addition to the local ROUTER. The next peer fails while creating its monitor PAIR. The exception escapes through onnewrequest() and the scheduler into the EngineCore loop:

text P2PSecondaryTierManager.getorcreatesession() -> ZmqTransport.connect() -> ZmqTransport.openconnection() -> monitorsock = self.zmqctx.socket(zmq.PAIR) -> zmq.error.ZMQError: Too many open files -> EngineDeadError

The process open-files limit was 65,536. The EngineCore had about 1,215 file descriptors at the failure point, so the failure was not the operating-system FD limit.

Boundary and controls

Each row below used a fresh vLLM process and pre-generated unique non-listening loopback ports.

| Test | Result | |---|---| | Default MAXSOCKETS=1023, 340 unique peers | 340 HTTP 200 responses; 340 active peers; service healthy | | Default limit, 344 unique peers, concurrency 4 | 340 HTTP 200 and 4 HTTP 500 responses; EngineCore and API exited | | Default limit, 344 unique peers, concurrency 1 | Same 340-peer ceiling and service exit | | Same endpoint repeated 512 times | 512 HTTP 200 responses; one active peer; service healthy | | 512 requests without P2P parameters | 512 HTTP 200 responses; no active peers; service healthy |

A diagnostic A/B changed only the context MAXSOCKETS value. Raising it from 1,023 to 2,048 moved the last fully successful point from 340 to 682 peers. The 683rd peer then raised the same ZMQError and terminated the service. The approximately 2.01x movement in the boundary identifies the ZeroMQ context quota as the exhausted resource.

The failure runs used logging-only instrumentation around openconnection() to record the context limit, peer count, and process FD count. It did not add or close any ZeroMQ socket and re-raised the original exception.

Related public work

PR #47843 is an open, unmerged proposal that identifies client-supplied P2P peer addresses as an SSRF risk and proposes API sanitization plus a configured peer allowlist. Those changes would block this public API trigger, but the PR does not add a connection deadline, session cleanup, or a capacity limit for never-established peers. This report adds the deterministic resource-exhaustion and service-exit impact of the retained state.

PR #49823 fixes cleanup and reconnection after a connection has been marked dead. A peer that never establishes does not receive the subscribed EVENTDISCONNECTED event, so it never enters that dead-state cleanup path.

Impact

This is uncontrolled resource consumption leading to denial of service. An attacker needs network access to an OpenAI-compatible inference endpoint and a normal API key when --api-key is enabled. The attacker does not need access to the internal P2P control or data ports and does not need any peer to answer.

Only deployments that explicitly enable OffloadingConnector, TieringOffloadingSpec, and a P2P secondary tier are affected. Repeating a cheap one-token request with unique non-listening endpoints steadily consumes scheduler and ZeroMQ resources. In the tested default context, about 341 requests were enough to terminate EngineCore and stop all inference on the instance until restart. Confidentiality and integrity were not affected; the demonstrated impact is availability loss.

This advisory was fixed in MR51504.

vLLM through 0.29.0 fetches and fully materializes remote or inline media before enforcing its documented media controls (the VLLMMAXAUDIOCLIPFILESIZEMB compressed-audio size cap, default 25 MB, and the per-modality --limit-mm-per-prompt item limits). Across four ingress paths — the shared media-acquisition layer (HTTPConnection.getbytes()/asyncgetbytes()), the chat completions audiourl/base64 path, the batch speech runner, and the Rust frontend POST /tokenize route — the server reads the entire HTTP response body, base64-decodes the inline payload, or spawns one fetch/decode task per media part, and only then applies the limit (or, on some paths, never applies it). A remote attacker can therefore cause the API server or batch-runner process to allocate memory and consume outbound bandwidth proportional to an attacker-chosen body size or media item count before the request is rejected, resulting in pre-inference memory and bandwidth exhaustion (denial of service). The chat and batch surfaces require an API key when one is configured; the Rust frontend /tokenize route is unauthenticated by design. There is no code execution or data disclosure impact.

vLLM versions through 0.29.0 contain a denial of service vulnerability in the NIXL connector's metadata handling for prefill/decode disaggregated deployments. Attackers can send requests with incomplete kvtransferparams dictionary entries to trigger an uncaught KeyError in EngineCore scheduling, causing the decode engine to terminate and making all routed requests fail until manual restart.

vLLM through 0.29.0 contains a denial of service vulnerability in the NIXL connector's prefix caching implementation that fails to properly validate block counts across multi-prompt completion requests in prefill/decode disaggregated deployments. Attackers can trigger an assertion failure in NixlBaseConnectorWorker.applyprefixcaching by submitting completion requests with multiple prompts of varying lengths, causing the decode worker to terminate and become unavailable until restarted.

vLLM through 0.29.0 contains a resource exhaustion vulnerability in MooncakeConnector where rejected prefill requests create ownerless transfer placeholders that are never reclaimed. Attackers can send rejected requests to exhaust sender task pools, causing valid requests to be delayed by up to 480 seconds while health checks continue returning success.

vLLM through 0.29.0 fails to validate the tpsize parameter in kvtransferparams on OpenAI-compatible completion endpoints, allowing attackers to allocate unbounded memory. Attackers can supply arbitrary tpsize values in prefill/decode disaggregated deployments to exhaust memory and trigger kernel OOM-kill of the decode worker process.

vLLM Mooncake connector through 0.29.0 fails to properly manage GPU KV cache block ownership when concurrent child requests share a single transfer ID in prefill/decode disaggregated deployments. Attackers can trigger GPU memory exhaustion by submitting completion requests with multiple prompts, causing orphaned KV cache blocks to accumulate until process restart and eventually preventing legitimate requests from executing.

vLLM through 0.29.0 fails to properly validate badwords token indices against the model's generation output width in SamplingParams.updatefromtokenizer(). Attackers can supply out-of-bounds token indices that corrupt logits memory of concurrent requests, causing different in-flight HTTP requests to return incorrect tokens.

vLLM through 0.29.0 fails to properly clean up decode-side metadata for rejected inference requests in prefill/decode disaggregated deployments. Remote attackers can submit requests with maxtokens=0 to exhaust decode-worker memory without bound until the worker restarts.

vLLM through 0.29.0 contains a memory corruption vulnerability in the Triton bincountkernel where prompt token IDs index the penalty prompt-presence bitset without bounds checking against vocabulary size. Attackers can submit multimodal audio requests with tokens equal to vocabulary size, causing out-of-bounds writes that corrupt concurrent requests' sampler state and alter repetition penalty behavior.