Los fallos de deserialización de NVIDIA TensorRT-LLM exponen rutas de control de inferencia distribuida

crítica

CVE

CVE-2025-33255, CVE-2026-24142

CWE

CWE-502

Sistemas afectados

NVIDIA TensorRT-LLM antes de la versión 1.2
Paquete PyPI tensorrt-llm antes de la versión 1.2
Despliegues del servidor MPI de TRT-LLM
Flujos de trabajo de inferencia y RLHF distribuidos de TensorRT-LLM que deserializan identificadores de IPC o de pesos
Clústeres de servicio de modelos autogestionados donde el tráfico de MPI/plano de control puede ser influido por inquilinos no confiables

NVIDIA publicó dos CVE de deserialización de TensorRT-LLM el 20 de mayo de 2026. Ambos afectan a NVIDIA/TensorRT-LLM antes de la versión 1.2; el paquete de Python correspondiente es tensorrt-llm.

CVE-2025-33255: deserialización insegura en la ruta del servidor MPI de TRT-LLM.
CVE-2026-24142: deserialización insegura de identificadores serializados.

Actualmente NVD puntúa ambos como CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H con una puntuación base crítica de 9.8. Los vectores de la CNA de NVIDIA son más bajos y están orientados a privilegios locales: 7.5 para CVE-2025-33255 y 6.3 para CVE-2026-24142. Esa diferencia de puntuación importa para el triaje. El riesgo práctico depende de si un atacante puede influir en los datos de MPI/plano de control, en los identificadores de IPC serializados o en las rutas de orquestación que mueven el estado del modelo entre rangos y workers.

El componente vulnerable no es un endpoint de framework web. Es el plano de control de inferencia distribuida que se sitúa detrás de los flujos de trabajo de servicio de LLM y RLHF. En una máquina de laboratorio de un solo inquilino, eso puede requerir acceso local. En una plataforma de modelos autogestionada, un clúster de GPU compartido, un entorno de notebook o un servicio de inferencia multiinquilino, la misma primitiva puede estar cerca de entradas de modelo, trabajo o worker controladas por el inquilino.

Paquete y proyecto afectados

Afectado:

proyecto: NVIDIA/TensorRT-LLM
paquete: tensorrt-llm
rango vulnerable: versiones anteriores a 1.2
línea base corregida: 1.2 o posterior, preferiblemente 1.2.1 o más reciente cuando esté disponible

El inventario debe incluir imágenes de contenedor y wheels internas, no solo las entradas directas de requirements.txt. Los despliegues de TensorRT-LLM suelen empaquetarse en imágenes de servicio de GPU, por lo que una aplicación puede estar expuesta incluso cuando el repositorio de la aplicación no nombra directamente tensorrt-llm.

Por qué importa pickle aquí

pickle de Python no es un formato de datos en el sentido de JSON o protobuf. Es un formato de bytecode para reconstruir objetos de Python, y la reconstrucción puede importar módulos y llamar a funciones elegidas por el atacante. Un patrón inseguro mínimo se ve así:

import pickle

obj = pickle.loads(untrusted_bytes)

Un pickle controlado por el atacante puede definir un reductor que mapea la deserialización a la ejecución de procesos:

class RunsCode:
    def __reduce__(self):
        import os
        return (os.system, ("id >&2",))

Ese gadget ilustrativo no es específico de TensorRT-LLM; es la clase de fallo. Cualquier ruta de código que trate un blob de pickle como datos estructurados ordinarios tiene que demostrar que el blob es confiable y que todos los objetivos de reconstrucción invocables son seguros. Las correcciones de TensorRT-LLM muestran que las rutas vulnerables involucraban exactamente este tipo de límite de confianza.

Identificadores de pesos serializados

El rastro de código público más claro está en tensorrt_llm/llmapi/rlhf_utils.py. Antes de la corrección, update_weights() aceptaba identificadores de IPC serializados indexados por UUID de dispositivo GPU y decodificaba una cadena en base64 directamente en pickle.loads():

serialized_handles = ipc_handles[device_uuid]
if isinstance(serialized_handles, str):
    all_handles = pickle.loads(base64.b64decode(serialized_handles))

Eso es peligroso porque ipc_handles es un objeto del plano de control. En flujos de inferencia distribuida y RLHF, representa identificadores entre procesos para los pesos del modelo, no datos orientados al usuario final. Pero si un atacante puede influir en ese objeto a través de un worker comprometido, un trabajo malicioso, un estado de orquestación envenenado o una API de gestión expuesta, el paso de deserialización se convierte en un límite de ejecución de código.

NVIDIA sustituyó la llamada directa a pickle por un unpickler restringido en tensorrt_llm.serialization:

decoded_data = base64.b64decode(serialized_handles)
all_handles = serialization.loads(
    decoded_data,
    approved_imports=approved_imports,
    approved_module_patterns=[r"^torch.*"],
)

if not isinstance(all_handles, list):
    raise ValueError(
        f"Deserialized data must be a list, got {type(all_handles).__name__} instead"
    )

La primera corrección pasó de la carga de objetos sin restricciones a un modelo de lista de permitidos. El endurecimiento posterior ajustó la aprobación del patrón de módulo torch.* a listas de permitidos explícitas de clases y dtypes para los objetos de identificador de tensor que TensorRT-LLM realmente necesita. Ese segundo paso importa: las expresiones regulares de módulo amplias reducen la exposición pero aun así dejan una superficie de importación grande. Para la deserialización, la lista de permitidos más segura es tan pequeña como lo permita el grafo de objetos esperado.

Riesgo del servidor MPI

CVE-2025-33255 cubre el lado del servidor MPI de TRT-LLM. MPI a menudo se trata como infraestructura interna de confianza, pero en los sistemas de servicio de modelos modernos puede situarse detrás de planificadores, lanzadores de workers, escalado dinámico, trabajos de notebook y mallas de servicio. La pregunta clave no es “¿esto está expuesto a Internet?”. La pregunta clave es “¿puede un principal no confiable hacer que bytes lleguen a la ruta de deserialización del servidor MPI?”.

Los patrones de alto riesgo incluyen:

clústeres de GPU compartidos donde distintos inquilinos pueden enviar trabajos de TensorRT-LLM;
plataformas de inferencia que permiten a los clientes subir o seleccionar artefactos de modelo, adaptadores o definiciones de trabajo;
despliegues de Kubernetes donde pods comprometidos pueden alcanzar puertos de control de MPI o de workers;
ejecutores de CI o de benchmarks que ejecutan experimentos de servicio de modelos no confiables;
APIs internas que aceptan identificadores serializados, metadatos de checkpoint o estado de worker y los reenvían a TRT-LLM.

Si esos límites existen, un fallo de deserialización en código del plano de control no es solo un problema de endurecimiento local. Puede convertirse en movimiento lateral desde un trabajo de modelo ordinario hacia la cuenta del worker de servicio, y desde ahí hacia los pesos del modelo, credenciales, GPUs o servicios adyacentes.

Remediación

Actualiza TensorRT-LLM a la versión 1.2 o posterior. Prefiere 1.2.1 o la versión estable más reciente disponible para tu CUDA, controlador, TensorRT y plataforma de GPU. Reconstruye los contenedores de servicio después de la actualización del paquete; no confíes solo en cambiar la capa de aplicación si tensorrt-llm está integrado en una imagen base.

Comprueba los entornos de Python:

python -m pip show tensorrt-llm
python - <<'PY'
import importlib.metadata
print(importlib.metadata.version("tensorrt-llm"))
PY

Para contenedores:

docker run --rm your-image python -m pip show tensorrt-llm

Para forks autogestionados o compilaciones parcheadas por el proveedor, inspecciona los puntos de llamada de deserialización. La forma vulnerable es la carga de pickle sin restricciones desde valores que pueden cruzar límites de proceso, worker, modelo o inquilino:

rg "pickle\.loads|pickle\.load" tensorrt_llm
rg "serialization\.loads" tensorrt_llm/llmapi

El patrón corregido debe usar un unpickler restringido, listas de permitidos estrechas y validación de tipos después de la deserialización. No sustituyas la corrección por comprobaciones de cadenas ad hoc sobre la entrada de pickle; las cargas útiles de pickle son bytecode, no texto.

Endurecimiento

Trata el tráfico de control de TensorRT-LLM como privilegiado:

restringe los puertos de control de MPI y de workers a los nodos de servicio que los necesitan;
aísla los trabajos de inquilinos con NetworkPolicy de Kubernetes, grupos de seguridad o controles equivalentes;
evita compartir una cuenta de worker de TRT-LLM entre límites de confianza;
evita que las rutas ordinarias de subida de modelos o benchmarks pasen objetos de Python serializados en crudo a los workers de servicio;
registra los reinicios de workers, la creación inesperada de sesiones MPI y los fallos de deserialización;
rota las credenciales presentes en los contenedores de servicio si hay evidencia de que un trabajo no confiable alcanzó las rutas vulnerables antes de aplicar el parche.

La lección más amplia es que los frameworks de servicio de IA contienen cada vez más sus propios sistemas distribuidos: planificadores, IPC, MPI, identificadores de tensores, carga de plugins y pipelines de artefactos de modelo. Estas son superficies de seguridad de aplicaciones. Merecen la misma revisión de límites de confianza que los manejadores HTTP y los consumidores de colas, especialmente cuando deserializan objetos de Python.

De la investigación a la remediación

Comprueba si este patrón existe en tu código

Convierte esta investigación en un flujo de remediación. Analiza dependencias y manifiestos para detectar riesgos similares en la cadena de suministro y prioriza las correcciones con contexto de alcanzabilidad.

Explorar el análisis de dependencias Solicitar demo