trust_remote_code=False no es una frontera: la RCE recurrente al cargar modelos en vLLM

En resumen En vLLM, --trust-remote-code=False debería impedir que un repositorio de modelo ejecute Python arbitrario en su host de inferencia. CVE-2026-27893, divulgada el 27 de marzo de 2026 (CVSS 8.8), es la tercera vez que se elude esa frontera — esta vez porque dos archivos de modelo fijan trust_remote_code=True. Afecta a las versiones 0.10.1 a 0.17.x; la corrección llegó en la 0.18.0. La lección no es un fallo aislado sino un patrón: un opt-in archivo por archivo no es una frontera de confianza.

¿Qué es esto?

CVE-2026-27893 es un fallo de mecanismo de protección (CWE-693) en vLLM, el motor de inferencia y servicio que sustenta una gran parte de los despliegues de LLM en producción. Los operadores pueden pasar --trust-remote-code=False para rechazar la ejecución del Python incluido en un repositorio de modelo. El aviso de seguridad de GitHub, publicado el 27 de marzo de 2026, muestra que dos archivos de implementación de modelo ignoran ese ajuste y pasan un literal trust_remote_code=True a Hugging Face Transformers — así que el código remoto se ejecuta de todos modos.

Lo que merece cobertura no es la CVE aislada sino su linaje. El propio aviso nombra a dos predecesores: CVE-2025-66448 (1 de diciembre de 2025, la ruta de carga de configuración vía auto_map) y CVE-2026-22807 (la ruta auto_map más amplia en el arranque). Cada una se corrigió; cada vez la misma frontera de confianza volvió a caer por una ruta de código distinta. CVE-2026-27893 es la tercera de esa serie.

Cómo funciona

La elección del operador se propaga correctamente por la jerarquía de configuración de vLLM como self.config.model_config.trust_remote_code. Los dos puntos de llamada vulnerables simplemente no lo leen. Según el aviso, las líneas culpables son:

# vllm/model_executor/models/nemotron_vl.py (carga del codificador de visión)
AutoModel.from_config(config, trust_remote_code=True)

# vllm/model_executor/models/kimi_k25.py (carga del procesador de imagen)
cached_get_image_processor(model_name, trust_remote_code=True)

Como el literal True anula el ajuste global, Hugging Face Transformers descarga y ejecuta Python desde el repositorio referenciado en el momento de la carga, con los privilegios del proceso vLLM. La ruta de activación: un atacante publica un repositorio de modelo dirigido a la arquitectura Nemotron-VL o Kimi-K25; un operador lo carga — creyendo que --trust-remote-code=False lo protege; vLLM despacha hacia uno de esos dos archivos; el True fijado en código gana; el código del repositorio se ejecuta. El bypass es silencioso — ninguna advertencia ni entrada de registro señala que el ajuste del operador fue ignorado. El CVSS lo califica en 8.8 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H): accesible por red, sin privilegios del atacante, pero el operador debe iniciar la carga (UI:R).

Por qué importa

La recurrencia es lo central. vLLM delega el comportamiento específico de cada modelo a archivos individuales en model_executor/models/, y cada archivo debe respetar de forma independiente la bandera global trust_remote_code. No existe ningún punto central que impida a un archivo fijar True. El resultado: cada nueva implementación de modelo es una ocasión de reintroducir la misma clase — que es exactamente lo que ocurrió tres veces, a través de config.py, la ruta auto_map en el arranque y ahora dos archivos de modelo.

Para los defensores, el peligro práctico es una falsa sensación de seguridad. Los equipos que adoptaron --trust-remote-code=False como control pueden estar cargando modelos por una ruta afectada sin indicación alguna de que el control es inoperante. Y la lección va más allá de vLLM: cualquier framework que disperse la aplicación de un ajuste crítico de seguridad en múltiples archivos independientes, sin mediación centralizada, está estructuralmente expuesto a este fallo. En el momento de la divulgación no había prueba de concepto pública ni evidencia de explotación activa, pero las versiones afectadas abarcan un año de lanzamientos (0.10.1 a 0.17.x).

Defensas

1. Actualice a vLLM 0.18.0 o posterior. La corrección de la PR #36192 reemplaza el True fijado en código por self.config.model_config.trust_remote_code en ambos puntos de llamada. Compruebe su versión con pip show vllm.
2. No haga de trust_remote_code=False su única frontera. Ejecute la inferencia en un contenedor mínimo con salida de red restringida, aísle la capa de servicio de los almacenes de datos sensibles y segméntela para limitar el movimiento lateral en caso de compromiso.
3. Verifique la procedencia de los modelos. Restrinja la carga a editores de confianza y firmados; calcule sumas de verificación o firme los artefactos de modelo antes de cargarlos en lugar de depender de una bandera de ejecución — sobre todo para las arquitecturas Nemotron-VL y Kimi-K25.
4. Escanee sus propios builds. Como esta clase ha reincidido, busque en model_executor/models/*.py los literales trust_remote_code=True (y las llamadas from_pretrained / from_config que no propaguen la configuración) en cualquier vLLM personalizado o bifurcado. Integre esa comprobación en su CI para que un futuro archivo de modelo no pueda reintroducirla.
5. Vigile el bypass silencioso. En entornos donde los modelos están precacheados, una descarga saliente de .py desde huggingface.co durante la carga — o un proceso hijo inesperado bajo un worker de vLLM — es una señal útil de caza que indica que se ejecutó código remoto cuando no debía.

Estado

Elemento	Referencia	Fecha	Notas
Aviso CVE-2026-27893	GitHub (GHSA-7972-pg2x-xr59)	2026-03-27	trust_remote_code=True fijado en código, CVSS 8.8, CWE-693
Versiones afectadas	vLLM	0.10.1 → 0.17.x	Rutas de carga Nemotron-VL y Kimi-K25
Versión corregida	vLLM 0.18.0	—	PR de corrección #36192
CVE-2025-66448	GitHub (GHSA-8fr4-5q9j-m8gm)	2025-12-01	Primer bypass, auto_map en la ruta de configuración
CVE-2026-22807	Aviso de GitHub	2026	Segundo bypass, ruta auto_map más amplia en el arranque

El encuadre correcto no es «parchear una CVE». Es que trust_remote_code en vLLM ha resultado ser una frontera porosa tres veces seguidas, y una pila de servicio que confíe en ella como control firme debería añadir aislamiento y verificaciones de procedencia que no dependan de una única bandera, archivo por archivo, correctamente configurada.