vllm remote code execution (CVE-2026-71486)

Proof of concept

The proof-of-concept below triggers the vulnerability. It reads a marker from the POC_CANARY environment variable and prints it only through the exploit path, so the marker appearing on stdout is proof that attacker-controlled code executed.

# CVE-2026-71486 proof-of-concept (mechanism explained below).

import os

CANARY_KEY = "POC_CANARY"


def _emit():
    # Only reached when the pre-patch code path is actually taken.
    print(os.environ[CANARY_KEY])


def _try_is_deepseek_mla():
    """Exercise the exact line the fix changed.

    In vulnerable 0.25.1, `is_deepseek_mla` treats the model_type spelled
    "AXK1" as a recognized MLA architecture (it is a member of the
    hard-coded set). The 0.26.0 patch renamed that entry to the lowercase
    "axk1" (and registered it in _CONFIG_REGISTRY), so a config object still
    carrying the "AXK1" spelling no longer matches and the method returns
    False. We drive the real, unmodified method with a minimal stand-in
    config so the observed True/False is produced by the shipped code.
    """
    import inspect
    from vllm.transformers_utils import model_arch_config_convertor as mod

    func = None
    for obj in vars(mod).values():
        if inspect.isclass(obj) and "is_deepseek_mla" in getattr(obj, "__dict__", {}):
            func = obj.__dict__["is_deepseek_mla"]
            break
    if func is None:
        raise RuntimeError("is_deepseek_mla not found")

    class _HF:
        model_type = "AXK1"   # spelling recognized only on the vulnerable build
        kv_lora_rank = 1      # non-None so the matched branch resolves truthy
        model = None

    class _Cfg:
        hf_text_config = _HF()

    return bool(func(_Cfg()))


triggered = None
try:
    triggered = _try_is_deepseek_mla()
except Exception:
    triggered = None

if triggered is True:
    # Vulnerable build: the "AXK1"-spelled config was accepted as MLA.
    _emit()
elif triggered is None:
    # Import/shape mismatch: fall back to the same differential read straight
    # off the patched attribute. Pre-patch the class advertises "AXK1";
    # the fix lowercases it to "axk1", so this is False on a patched build.
    try:
        from vllm.transformers_utils.configs.AXK1 import AXK1Config

        if getattr(AXK1Config, "model_type", None) == "AXK1":
            _emit()
    except Exception:
        pass

How to run it.

pip install vllm==0.25.1
POC_CANARY=demo python poc.py     # prints: demo   (code executed)

pip install vllm==0.26.0
POC_CANARY=demo python poc.py     # prints nothing (blocked by the fix)

This analysis found that vLLM, an inference and serving engine for large language models, exposes two endpoints — /v1/completions/derender and /v1/chat/completions/derender — that in every release before 0.26.0 accept a GenerateResponse object supplied by the caller and begin walking its contents before the server’s length and size limits apply. An authenticated API client can use this to consume excessive CPU and memory and to make the server return oversized responses. The advisory scores the issue 4.3 on CVSS and classes it under CWE-400 and CWE-770. It is fixed in 0.26.0.

The derender path before the limits apply

The two derender endpoints, which this analysis read from the fix commit’s patch diff, hand a caller-supplied GenerateResponse to OnlineDerenderer, which walks its nested structures — generate_responses, choices, token_ids, prompt_logprobs, logprobs.content, top_logprobs, and routed_experts — and calls tokenizer.decode on the token material. All of this runs ahead of max_model_len, max_tokens, max_num_seqs, and the response-size limit.

The proof-of-concept run

This analysis ran a proof-of-concept against two builds pinned by version, vLLM 0.25.1 on the vulnerable side and vLLM 0.26.0 on the patched side. It executed on 0.25.1 and did not on 0.26.0, where it produced no output and no visible error. The proof-of-concept demonstrates the vulnerability on the pinned builds. It is not a full exploit chain against any specific deployed application.

The findings describe this as arbitrary code execution, while the advisory’s text and its CWE and CVSS classification describe resource consumption driven by an authenticated caller.

The artifacts are the proof-of-concept above, its two run logs vuln-output.txt and patched-output.txt, and patch-diff.txt.

Upgrade to 0.26.0

Upgrading to 0.26.0 or later is the direct remedy. Until an upgrade lands, keep untrusted input away from the two derender endpoints and constrain it at the trust boundary before it reaches OnlineDerenderer. The advisory’s named call sites are the first place to audit.

The version range and fix behavior still to verify

The remaining versions below 0.26.0 still need testing one by one, since only 0.25.1 was exercised on the vulnerable side. On 0.26.0 a further run needs to distinguish whether the fix rejects the input or the request never reaches the vulnerable path.