vLLM LlavaOnevision2 ignores trust_remote_code: code bundled in a malicious model runs even when you turned it off

Who is affected

The official range is ”< 0.28.0”. LlavaOnevision2 support was added in 0.25.0 (2026-07-11, PR #44785). We checked the 0.25.0 source: the processor loader already passed trust_remote_code to a function that does not take that parameter, and fix PR #52952 changes that same file. Earlier versions do not have this model, so the versions actually affected are 0.25.0 up to, but not including, 0.28.0.

According to the advisory, all of these must hold: the user loads a LlavaOnevision2 model with vLLM; the model comes from an untrusted source; the user relies on trust_remote_code=False for protection; vLLM treats the architecture as built-in, so the config loads without the remote-code check; and multimodal processing (handling images, video and text together) is triggered. Whether the malicious code runs at startup or on the first multimodal request is unconfirmed.

How it works

An AI model repository can contain more than weights: it can also ship Python files that prepare inputs such as images or video. trust_remote_code is the switch that decides whether that bundled code may run. Setting it to False means it should not.

vLLM’s function for loading the LlavaOnevision2 processor, _load_ov2_processor(), called the Transformers function get_class_from_dynamic_module() directly and passed trust_remote_code to it. The problem: that function has no such parameter. The value was accepted by **kwargs (Python syntax for “accept any extra arguments”), and nothing ever read it or raised an error. So whatever the user had set, the model’s processor module was imported. According to the advisory, the code sits at the top level of the module, so it runs the moment the module is imported, with the full privileges of the vLLM process.

vLLM already had a safe wrapper, try_get_class_from_dynamic_module(), which calls resolve_trust_remote_code() first. The MiniCPM-V loader used it correctly; the LlavaOnevision2 path skipped it.

The flawed approach (conceptual illustration, not the original source code):

def get_class_from_dynamic_module(ref, repo, **kwargs):
    # trust_remote_code isn't declared; nothing reads the value in kwargs
    return import_from_repo(ref, repo)

cls = get_class_from_dynamic_module(ref, repo, trust_remote_code=False)  # still imports

The fixed approach:

if not resolve_trust_remote_code(trust_remote_code, ...):
    raise ValueError("trust_remote_code is off")  # stop before importing
cls = get_class_from_dynamic_module(ref, repo)

What does “remote code execution” mean here? The CVE description uses the phrase, but both score vectors say Attack Vector Local (AV:L) plus User Interaction. “Remote” refers to code arriving with a downloaded model, not to someone attacking a running server over the network.

Weakness types: the GHSA lists CWE-94 (code injection) and CWE-829 (inclusion of functionality from an untrusted source); the CVE record, NVD and VulnCheck list only CWE-94.

Timeline

Per the input record, this vulnerability is not in CISA’s Known Exploited Vulnerabilities (KEV) catalog, and none of the sources read for this page mention exploitation in the wild.

Further reading

• Scoring differences: the vLLM maintainers’ GitHub advisory rates it CVSS 3.1 7.8 (High). The CVE record, published by VulnCheck, adds CVSS 4.0 8.5 (High) and also carries the 3.1 score of 7.8. NVD labels both scores as “Secondary” scores supplied by VulnCheck and shows no score of its own. The two scores use different CVSS versions; neither is wrong.
• Compared with CVE-2026-5241 (Transformers): that flaw is in Transformers’ LightGlue model loading path, where config data inside the model overrides the user’s trust_remote_code=False; it is fixed in Transformers 5.5.0 (the CVE record’s range is “before 5.5.0”). Here the setting was ignored, because it went to a function that doesn’t accept it. The result is the same in both cases: the user turned the switch off, and the model’s Python code ran anyway.
• Lesson for developers: don’t count on a downstream function to honor a safety flag for you. Check it yourself before the dangerous call, and stop if the check fails.
• Reporter: NLx64; coordinator: jperezdealgaba. “ov2” means LlavaOnevision2, not another product.