Un archivo de configuración no debería ejecutar nada

Un desarrollador de un fabricante europeo descarga un modelo de un hub público, llama a from_pretrained y se va a comer. La biblioteca obtiene los pesos, lee el archivo JSON que los describe e inicializa. Nada en esa secuencia parece un consentimiento para ejecutar código ajeno, y el desarrollador ya ha fijado trust_remote_code en False precisamente para que no lo sea.

Los investigadores de Pluto Security demostraron que sí lo era. El fallo se identifica como CVE-2026-4372, tiene una puntuación base CVSS de 7,8 y se clasifica bajo CWE-502, deserialización de datos no confiables. Convierte una descarga rutinaria de un modelo en la ejecución arbitraria de código Python en la máquina que la realiza, y la acción requerida del usuario no es otra que la forma documentada de cargar un modelo.

Cómo un campo de metadatos esquivó el flag

El flag protege los archivos de código. El ataque llegó en los metadatos. El constructor de la configuración contenía un bucle que tomaba cada clave y cada valor del JSON no confiable y los escribía directamente en el objeto de configuración, sin lista de permitidos y sin validación. Entre los campos que un atacante podía fijar por esa vía había uno llamado _attn_implementation_internal, un atributo interno privado que nadie esperaba que fuera accesible desde un archivo descargado.

Cuando ese campo contenía una cadena con la forma de propietario y repositorio, el cargador de kernels la interpretaba como un paquete que debía obtener del hub y lo importaba sin comprobación de seguridad alguna. Cualquier código Python colocado en el archivo de inicialización de ese repositorio se ejecutaba entonces. El mecanismo de consentimiento en el que confían los desarrolladores nunca llegó a consultarse, porque su alcance era el código de modelado personalizado y esto no era código de modelado personalizado. Era un archivo de ajustes.

El parche llegó primero. El aviso tardó otros 81 días

Las fechas son la historia. El código vulnerable entró en la biblioteca el 29 de agosto de 2025 y se distribuyó en todas las releases durante unos seis meses. El fallo se comunicó a través de un bug bounty el 23 de febrero de 2026, un mantenedor abrió la corrección el 2 de marzo y la versión 5.3.0 la cerró el 4 de marzo. Se trata de una respuesta rápida y encomiable, diez días desde la comunicación hasta la release con el parche.

Después, el registro público quedó en silencio. CVE-2026-4372 no se publicó hasta el 24 de mayo de 2026, 81 días después de que la corrección ya estuviera disponible en una release pública. En ese intervalo el parche se describió en las notas de la release como un problema de seguridad del paquete kernels, sin número de CVE, sin gravedad y sin mención alguna de que impedía la ejecución remota de código. Cualquier operador cuya gestión de parches se activa a partir de fuentes de CVE y avisos del proveedor, que es la mayoría de los operadores regulados en Europa, no tuvo señal alguna para priorizar una actualización que ya estaba disponible.

Después el propio hub fue vulnerado por la misma clase de puerta

El 16 de julio de 2026 Hugging Face reveló una intrusión en una parte de su propia infraestructura de producción. Un conjunto de datos malicioso abusó de dos vías de ejecución de código en el procesamiento de conjuntos de datos, un cargador de conjuntos de datos con código remoto y una inyección de plantilla en la configuración de un conjunto de datos, para ejecutarse en un worker de procesamiento. Desde ahí el intruso escaló hasta el acceso a los nodos, recolectó credenciales de nube y de clúster y se movió lateralmente hacia varios clústeres internos a lo largo de un fin de semana. El análisis forense revisó más de 17.000 acciones registradas.

Hugging Face afirma que no encontró indicios de manipulación de modelos, conjuntos de datos ni Spaces públicos, y que verificó que su cadena de suministro de software estaba limpia. Conviene tomar el incidente como prueba de la vía de escalada y no como motivo para desconfiar del hub. Un archivo que describe datos llegó hasta un worker, y el worker tenía credenciales. Esa es la forma del riesgo, y es la misma forma que la del fallo de configuración anterior.

Qué conviene resolver antes de su próxima descarga de un modelo

Tres comprobaciones, por este orden. Confirme qué versión de transformers se ejecuta en sus imágenes de entrenamiento, en sus notebooks y en sus agentes de compilación, y actualice todo lo que esté por debajo de 5.3.0. Determine si el paquete kernels está instalado junto a ella, ya que eso es lo que hizo explotable la vía. Después examine qué credenciales residen en las máquinas que analizan artefactos de modelos y de conjuntos de datos, porque a esas máquinas se las suele tratar como mera infraestructura de transporte de datos y se les concede un acceso amplio en consecuencia.

El deber de notificación corre por su propio reloj al margen de todo esto. Según el artículo 23 de la NIS2, una entidad dentro del ámbito de aplicación debe a su autoridad nacional una alerta temprana en las 24 horas siguientes a tener conocimiento de un incidente significativo, una notificación más completa en 72 horas y un informe final en el plazo de un mes. En España la orientación equivalente procede del INCIBE-CERT. Ninguno de esos plazos se detiene mientras usted averigua qué versión de la biblioteca estaba ejecutando.

Leer a continuación: Una petición podía secuestrar tu sitio WordPress  |  Parchear SharePoint ya no cierra la puerta