vLLM vulnerável à execução remota de código via transformers_utils/get_config

The impact of this vulnerability is severe. An attacker can achieve remote code execution simply by providing a specially crafted model configuration file to a vulnerable vllm instance. This allows them to gain complete control over the affected system, potentially leading to data theft, system compromise, and further lateral movement within the network. The ability to bypass the trustremotecode=False setting significantly increases the attack surface and makes exploitation easier. This vulnerability shares similarities with other remote code execution flaws where dynamic code loading is mishandled, potentially allowing attackers to inject malicious code into the application's runtime environment.

Organizations deploying vllm for large language model inference, particularly those using custom model configurations or integrating vllm into automated pipelines, are at significant risk. Shared hosting environments where multiple users can upload model configurations are especially vulnerable, as a malicious configuration from one user could compromise the entire system.

• python / supply-chain:

import os
import subprocess

def check_vllm_version():
    try:
        result = subprocess.check_output(['pip', 'show', 'vllm'], stderr=subprocess.STDOUT)
        version = result.decode('utf-8').split('Version: ')[1].strip()
        if version <= '0.9.2':
            print(f"vllm version is vulnerable: {version}")
        else:
            print(f"vllm version is patched: {version}")
    except FileNotFoundError:
        print("vllm is not installed.")
    except subprocess.CalledProcessError as e:
        print(f"Error checking vllm version: {e}")

check_vllm_version()

• linux / server:

ps aux | grep -i vllm
journalctl -u vllm | grep -i "auto_map"

• generic web: Inspect model configuration files for suspicious auto_map entries pointing to external repositories. Examine access logs for requests related to model loading and configuration.

1. 2025-12-02Disclosure

   disclosure

2. 2025-12-02Patch

   patch

1. Reservado2025-12-01
2. Publicada2025-12-02
3. EPSS atualizado2026-03-23

The primary mitigation is to upgrade to vllm version 0.11.1 or later, which addresses the vulnerability. If upgrading immediately is not feasible, consider implementing strict input validation on model configuration files to prevent the inclusion of malicious auto_map entries. While not a complete solution, this can reduce the attack surface. Monitor vllm logs for suspicious activity related to dynamic module loading or unexpected Python code execution. Implement network segmentation to limit the potential blast radius if a system is compromised. After upgrading, verify the fix by attempting to load a known malicious configuration file and confirming that it is rejected or handled safely.