VLLM · GHSA-w4cg-mhc7-mgw3 · AI agents & MCP
FIX → 0.31.0
A client allowed to call vLLM's OpenAI-compatible API can pass request-level mm_processor_kwargs that make the MiniMax M3 video processor enlarge frames without limit. The resulting oversized allocations and CPU work can exhaust host memory and disrupt the worker or service.
first public Oct 27, 2026 · 1 source
Could this affect your app?
Free first check from your website. Connect your repo for the full answer.
The flaw is in vLLM's video preprocessing for MiniMax M3 VL models, so a deployment is exposed when it serves that model and accepts video requests from clients it does not fully trust. Any client allowed to call the OpenAI-compatible chat or responses API can reach the vulnerable path through request-level mm_processor_kwargs. Deployments that do not serve MiniMax M3 or do not accept video input are not affected by this path.
Not affected if no-minimax-m3-deployment, no-video-input
Who cares minimax-m3, openai-compatible-api, self-hosted, vllm
pip show vllm or python -c "import vllm; print(vllm.__version__)" and compare against >= 0.24.0, < 0.31.0--trust-request-mm-kwargs is enabled, since the fix keeps it disabled for untrusted clientsUpgrade to 0.31.0
Description
A client allowed to call the OpenAI-compatible API can pass request-level mm_processor_kwargs to the MiniMax M3 VL video processor. The processor accepts min_pixels without a numeric range or relationship check. A large value can enlarge every decoded frame well beyond the default per-frame max_pixels value.
The processor has a fixed width × height × frame-count budget, but it applies that check only when max_long_side_pixel is set. Its default value is None, so the normal area-based resize path skips the video-wide budget and proceeds to resize, normalize, reshape, and concatenate the enlarged tensors before later engine validation.
This can cause disproportionate host-memory allocation and CPU work from one video request and may disrupt the worker or service. I confirmed the complete request-to-allocation path by static source review. I did not run vLLM, a model, a server, a GPU workload, or an executable proof of concept, so I am not claiming a measured out-of-memory threshold or a guaranteed process crash.
I assessed vLLM v0.28.0. The same vulnerable conditions are present in every inspected release from v0.24.0 through v0.29.0; no patched release was available when I checked on 2026-09-09.
Check it with your coding agent
It reads this page and tells you if your code is affected.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
0.31.0--trust-request-mm-kwargs disabled for untrusted clientsThe public chat and responses request schemas expose mm_processor_kwargs as dict[str, Any]:
The renderer forwards this dictionary as the request's multimodal processor defaults, and inference-time values override the startup values:
The common processor wrapper filters keyword names but does not validate the numeric value or require min_pixels <= max_pixels. MiniMax's vLLM adapter then forces do_resize=True and passes the merged values to the processor:
smart_resize first checks whether the current frame is above max_pixels. If it is not, the elif branch may enlarge it to the request-controlled min_pixels. The function does not reject min_pixels > max_pixels:
if h_bar * w_bar > max_pixels:
beta = math.sqrt((height * width) / max_pixels)
h_bar = floor_by_factor(height / beta, factor)
w_bar = floor_by_factor(width / beta, factor)
elif h_bar * w_bar < min_pixels:
beta = math.sqrt(min_pixels / (height * width))
h_bar = ceil_by_factor(height * beta, factor)
w_bar = ceil_by_factor(width * beta, factor)
The video processor sets max_long_side_pixel = None and max_total_pixels = VIDEO_MAX_TOTAL_PIXELS. During preprocessing it deliberately passes max_total_pixels=None to the per-frame resize helper, intending to enforce the volumetric limit after the frame count is known. That later check is incorrectly conditional on max_long_side_pixel is not None:
resized_height, resized_width = smart_resize(
height,
width,
factor=factor,
min_pixels=min_pixels,
max_pixels=max_pixels,
max_long_side_pixel=max_long_side_pixel,
min_short_side_pixel=self.min_short_side_pixel,
max_total_pixels=None,
)
if (
max_long_side_pixel is not None
and resized_height * resized_width * num_frames
> self.max_total_pixels
):
raise ValueError(...)
With the default None value, the processor skips this check and materializes resized and normalized tensors before concatenating the processed videos at line 491. The v1 engine's prompt and encoder-cache checks run after multimodal preprocessing, so they cannot prevent this allocation.
The decode-time VLLM_MAX_IMAGE_PIXELS check also does not close the path: it constrains the dimensions of an input frame before decoding, while the vulnerable processor enlarges that frame afterward.
Public PR #51449, Bound request-controlled image and video geometry, reports the same broad class for 16 other multimodal processors. It does not list MiniMax M3 or the min_pixels, max_total_pixels, and max_long_side_pixel fields, and its patch does not modify either MiniMax file cited above. Its shared changes cap request-level frame count and a generic sampling loop; they do not reject min_pixels > max_pixels or make the MiniMax volumetric check unconditional. PR #51449 was closed without merge on 2026-08-10.
Public PR #53610 refactors the MiniMax adapter but continues forwarding the processor kwargs without these checks. PR #54935 fixes request-driven video sampling work in GLMGA, a different processor and sink. I therefore consider this report a MiniMax M3 sibling omitted from the public geometry-amplification work, rather than a separate vulnerability class. It may belong under the same advisory family at the maintainers' discretion.
Suggested remediation is to validate the merged processor values before allocation, including positive numeric bounds and min_pixels <= max_pixels, and to enforce resized_height * resized_width * num_frames <= max_total_pixels regardless of the selected resize mode. The check should run before self.resize.
The established impact is attacker-influenced CPU allocation and computation before request-level engine validation. On an exposed MiniMax M3 VL deployment, a permitted inference client can submit video work that consumes memory and CPU far out of proportion to the decoded input. Depending on available memory and process supervision, this may cause allocation failure, worker termination, restart, or temporary loss of service.
The finding does not establish confidentiality or integrity impact. It also does not establish a reliable crash threshold for every deployment. API authentication, proxy request limits, and host memory affect attack cost, but they do not enforce the missing relationship and volumetric checks inside the processor.
vllm (PyPI).>= 0.24.0, < 0.31.0.0.31.0.PR #58830 blocks untrusted per-request mm_processor_kwargs and media_io_kwargs by default before preprocessing. Keep --trust-request-mm-kwargs disabled for untrusted clients. Explicitly enabling it restores trusted override behavior; the underlying processor/sampler is not independently bounded by this fix.
Advisory fixed in #58830.