Una nueva investigación advierte sobre FaceHugger Diffusers: tres fallos de alta severidad en la biblioteca Diffusers de Hugging Face que podrían permitir a un atacante provocar ejecución remota de código (RCE) de forma “silenciosa”. El escenario típico es un entorno que carga modelos desde repositorios de terceros dentro de pipelines de producción, sistemas CI/CD o imágenes de contenedor.
El punto crítico es que el mecanismo de protección trust_remote_code, diseñado para impedir la ejecución de código no revisado en procesos de carga personalizados, puede eludirse mediante condiciones específicas durante la descarga y la inicialización de pipelines.
Qué es FaceHugger y por qué importa
El conjunto de vulnerabilidades ha sido denominado FaceHugger por los investigadores. La preocupación no es solo técnica: con la adopción creciente de repositorios y librerías del ecosistema de difusión para tareas de vídeo, imágenes y audio, las organizaciones integran con frecuencia estas dependencias en sus flujos automatizados.
Diffusers es un paquete de Python que actúa como biblioteca para modelos de difusión preentrenados. Permite generar contenido empleando componentes y pipelines que se configuran al cargar un modelo. En entornos empresariales, esa carga local desde un repositorio remoto puede convertirse en una superficie de ataque cuando el repositorio no es confiable o no ha sido auditado.
Cómo funciona el riesgo en Diffusers
Una de las capacidades centrales de Diffusers es la posibilidad de cargar modelos desde repositorios del hub usando la API DiffusionPipeline. Durante ese proceso, la biblioteca utiliza archivos de configuración para inicializar clases de pipeline y componentes, e incluso puede incorporar lógica de pipeline personalizada.
El parámetro trust_remote_code actúa como una barrera de seguridad: controla si el código Python alojado dentro de un repositorio de modelos puede ejecutarse durante la fase from_pretrained(). En términos prácticos, con True se permite la ejecución de código remoto; con False (o si se omite) la librería debería bloquear la ejecución de código no verificado.
Sin embargo, FaceHugger Diffusers muestra que el control no cubre todas las rutas por las que el cargador puede terminar “viendo” código que el guardián inicial no contabilizó.
La causa de fondo: TOCTOU y operaciones de red separadas
De acuerdo con el análisis, los distintos casos de RCE se rastrean a variantes del patrón Time-of-Check to Time-of-Use (TOCTOU). En lugar de tratar la descarga como una operación atómica única, el proceso de descarga se realiza mediante dos solicitudes HTTP secuenciales.
La consecuencia es que el material descargado puede cambiar entre la fase en la que se “comprueba” la confianza y la fase en la que se “usa” el artefacto para inicializar componentes y pipelines. Si la verificación del “trust” se ejecuta solo en la primera parte, un atacante puede aprovechar el desfase temporal para introducir contenido malicioso antes de que se emplee.
En otras palabras, los investigadores explican que el problema no es únicamente “si existe código remoto”, sino en qué momento exacto se evalúa la confianza y qué exactamente llega a ser cargado después.
Vulnerabilidades reportadas (CVE) y puntuación
Las vulnerabilidades identificadas se listan con sus CVE correspondientes y su severidad estimada. A continuación, un resumen orientado a entender el impacto y la vía de explotación.
CVE-2026-44827 (CVSS 8.8)
Esta falla describe una vulnerabilidad de inyección de código. Permite que se cargue código arbitrario a través del flujo custom_pipeline desde un repositorio en el hub mediante un pipeline manipulado con el nombre “None.py”. El punto alarmante es que puede ocurrir incluso cuando trust_remote_code está en false (o si se deja como valor por defecto al omitirlo).
CVE-2026-45804 (CVSS 7.5)
Aquí la raíz está en una condición de carrera relacionada con cómo se obtiene el contenido desde el hub. La descripción indica que el atacante podría introducir código arbitrario al modificar la configuración entre las llamadas hf_hub_download y snapshot_download hacia el hub, lo que podría acabar derivando en ejecución de código.
CVE-2026-44513 (CVSS 8.8)
Esta tercera vulnerabilidad vuelve al escenario de inyección de código. Permite cargar código arbitrario por la ruta de custom_pipeline desde un repositorio del hub, aun cuando trust_remote_code esté desactivado (o se omita).
Cuándo se considera afectado tu sistema
Tras la divulgación responsable, las correcciones se incorporaron en la versión Diffusers 0.38.0, publicada a inicios de mayo de 2026. Si tu entorno aún usa versiones anteriores, es recomendable revisar el inventario de dependencias y actualizar cuanto antes.
Los investigadores aclaran que cualquier uso que invoque DiffusionPipeline.from_pretrained con custom pipelines puede estar expuesto. Esto es especialmente relevante en procesos automatizados donde el modelo y su configuración se consumen de forma dinámica desde repositorios externos.
Por qué es una amenaza de cadena de suministro para IA
El análisis subraya una idea clave: en muchos flujos, los artefactos provenientes de repositorios de modelos se tratan como datos pasivos. Sin embargo, las configuraciones, los cargadores y el código de pipelines personalizados pueden cruzar la frontera entre “configurar” y “ejecutar”.
Así, un cargado rutinario de un modelo puede transformarse en un punto de acceso inicial si el sistema no asume que todo lo descargado podría ser malicioso. Con el aumento del uso de repositorios en empresas y el papel de bibliotecas como Diffusers en pipelines de producción, el impacto potencial crece.
Mitigaciones recomendadas si no puedes actualizar
Si actualizar inmediatamente no es una opción, el equipo del proyecto sugirió medidas prácticas para reducir el riesgo. Aunque estas recomendaciones no sustituyen el parche, pueden ayudar a limitar la superficie de ataque en el corto plazo.
- Usa from_pretrained con fuentes verificadas: llama a from_pretrained() usando pretrained_model_name_or_path, custom_pipeline y directorios locales de snapshot solo provenientes de orígenes completamente confiables y auditados.
- Evita mezclar repositorios de custom pipelines: no pases custom_pipeline apuntando a un repositorio del hub que sea distinto del que corresponde a pretrained_model_name_or_path antes de leer el pipeline.py.
- Inspecciona snapshots antes de cargarlos: antes de ejecutar from_pretrained con un snapshot local, revisa el contenido en busca de archivos *.py inesperados, especialmente en subdirectorios de componentes (por ejemplo, unet/, scheduler/) y en la raíz del snapshot.
Estas acciones se enfocan en un principio: reducir la confianza en artefactos no auditados y evitar que código arbitrario termine siendo ejecutado durante el proceso de carga.
Recomendaciones finales para equipos de seguridad
Si trabajas con cargas automáticas de modelos, considera revisar políticas internas para dependencias y repositorios. Asegúrate de que los procesos de CI/CD y los entornos de ejecución cuenten con controles que limiten la carga de código no revisado.
Con FaceHugger Diffusers como recordatorio, la lección es clara: incluso mecanismos de seguridad como trust_remote_code pueden fallar si el flujo de descarga y uso permite un desajuste temporal. Por eso, la actualización a Diffusers 0.38.0 debe ser prioritaria y, mientras tanto, la inspección y la confianza estricta en orígenes auditados son fundamentales.
En resumen, cargar modelos desde repositorios externos sin validación suficiente ya no puede considerarse un paso neutral. Trátalo como un componente más de tu estrategia de seguridad.
Fuente: https://thehackernews.com/2026/08/hugging-face-diffusers-flaws-could-let.html
