Secret Stealing: código de modelo manipulado exfiltra tus datos de fine-tuning

¿Qué es esto?

Secret Stealing Attacks on Local LLM Fine-Tuning through Supply-Chain Model Code Backdoors (arXiv 2604.27426, publicado el 30 de abril de 2026) ataca una suposición que muchos equipos consideran una frontera de privacidad infranqueable: creer que ajustar un modelo de pesos abiertos en máquinas propias, sin conexión mantiene privados los datos de entrenamiento. El artículo demuestra que no basta. El atacante no necesita tus pesos, ni tus datos, ni acceso de red a tu entrenamiento. Solo necesita que ejecutes su código de modelo —el Python que define la arquitectura—, y ese código puede memorizar de forma sigilosa y luego filtrar los secretos presentes en tu conjunto de fine-tuning.

Esto importa porque los conjuntos de fine-tuning locales suelen contener secretos de alta entropía: claves de API, tokens de acceso, identificadores personales, registros financieros. El ataque está diseñado para extraer precisamente esos elementos.

Cómo funciona

El vector de cadena de suministro es el código personalizado del modelo, no sus pesos. Muchos modelos de pesos abiertos distribuidos en plataformas como Hugging Face incluyen un modeling.py (o similar) que el cargador ejecuta en cuanto se pasa trust_remote_code=True. La idea de los autores es camuflar la lógica maliciosa como definiciones de arquitectura corrientes dentro de ese código, convirtiendo el envenenamiento pasivo de pesos en un secuestro activo de la ejecución durante el entrenamiento.

Los ataques previos de «envenenar los pesos preentrenados» funcionan con objetivos difusos en lenguaje natural, pero fallan con cadenas dispersas y de alta entropía como una clave: un prefijo probabilístico no reproducirá de forma fiable sk-[REDACTED]. El enfoque basado en el código del modelo evita ese problema. Según los autores, emplea un mecanismo de memorización determinista de extremo a extremo que fija los secretos a nivel de tokens en el flujo de cómputo en vivo mediante coincidencia de reglas tensoriales en línea, y luego inyecta gradientes de «robo» por desacoplamiento valor–gradiente, de modo que el secreto queda grabado en el modelo sin degradar la tarea principal. Una vez desplegado tu modelo ajustado, el atacante recupera los secretos a través de un canal de consultas de caja negra.

# Forma conceptual del riesgo — NO es un exploit funcional.
# Un archivo de modeling personalizado ejecutado vía trust_remote_code puede
# ejecutar lógica arbitraria dentro de la pasada forward/backward:
model = AutoModelForCausalLM.from_pretrained(
    "vendor/cool-new-model",
    trust_remote_code=True,   # <-- ejecuta el Python del proveedor, incluido modeling.py
)
# A partir de aquí, el código del modelo ve cada lote de entrenamiento —incluidos
# los secretos de tus datos de fine-tuning— y puede memorizarlos de forma determinista.

Los resultados reportados son contundentes: más del 98 % de Strict ASR (recuperación exacta del secreto) sin impacto medible en la tarea prevista del modelo ajustado, y se afirma que la técnica elude DP-SGD, la auditoría semántica y la auditoría de código.

Por qué importa

El modelo de amenaza derriba un atajo mental cómodo. «Ajustamos sin conexión, así que los datos no pueden salir» es falso en cuanto se ejecuta código de modelo no verificado. La frontera de confianza no es la red: es el código que permites ejecutar dentro de tu proceso de entrenamiento. Un resultado cercano de mayo de 2026, Be Careful When Fine-tuning On Open-Source LLMs (arXiv 2505.15656), llega a una conclusión complementaria desde el lado de los pesos: un proveedor puede implantar una puerta trasera de caja negra que luego recupera tus consultas de fine-tuning. En conjunto, demuestran que el pipeline de fine-tuning de pesos abiertos tiene varias superficies de robo de datos, y que «se ejecutó en mi hardware» no es una garantía de privacidad.

Cualquier organización que descargue un modelo comunitario y lo ajuste con datos internos sensibles —startups, empresas, sectores regulados— está dentro del alcance.

Defensas

El propio artículo muestra que DP-SGD y las auditorías ingenuas de código o semánticas son insuficientes: aborda esto como un problema de defensa en profundidad y no con un único control.

• Trata el código de modelo como código no confiable. Evita trust_remote_code=True en repositorios que no hayas revisado. Prefiere modelos que se carguen con arquitecturas estándar integradas y pesos safetensors, donde no se ejecuta Python del proveedor.
• Fija y revisa los archivos de modeling personalizados. Si debes usar código personalizado, incorpóralo a tu propio repositorio, fija un commit concreto, compáralo en cada actualización y haz que una persona lea lo que se ejecuta en forward/backward. Vigila cualquier código que inspeccione, calcule hashes o acumule los tensores de entrada en bruto.
• Aísla el proceso de entrenamiento. Ejecuta el fine-tuning en un entorno aislado (sandbox), sin acceso de red saliente y con permisos de archivo mínimos, para que ni el entrenamiento ni un eventual canal de «recuperación» posterior tengan una vía de salida.
• Reduce el botín. Limpia o tokeniza los secretos de tus datos de fine-tuning antes del entrenamiento; las claves de API, credenciales y datos personales en bruto, por lo general, no deberían estar en un corpus de entrenamiento.
• Monitoriza la salida. Sondea el modelo ajustado en busca de secretos memorizados (cadenas centinela, consultas de extracción) antes del despliegue, y limita/registra la superficie de consultas de caja negra que un atacante necesitaría para exfiltrarlos.

Estado

Se trata de investigación académica publicada que describe una clase de ataque sobre la cadena de suministro del fine-tuning de pesos abiertos, no de un exploit contra un producto desplegado concreto. Fechas clave: preprint de arXiv publicado el 30 de abril de 2026 (arXiv 2604.27426); el resultado cercano del lado de los pesos (arXiv 2505.15656) es de mayo de 2026. La lección práctica se mantiene con independencia de cualquier framework concreto: la ruta de ejecución trust_remote_code es una decisión de confianza en código y debe gobernarse como tal.