- Se presenta una investigación que sugiere que los desarrolladores que usan LLM en entornos locales para proteger la privacidad podrían quedar expuestos, en cambio, a vulnerabilidades de seguridad
- En un experimento del OpenAI Red‑Teaming Challenge sobre el modelo
gpt-oss-20b, el equipo de investigación confirmó que los modelos locales son mucho más fáciles de engañar con manipulación de prompts y terminan generando código malicioso
- Con una simple manipulación del prompt, un atacante puede inducir la inserción de backdoors o incluso la ejecución remota de código (RCE), con tasas de éxito de hasta 95%
- Estos ataques pueden infiltrarse de forma natural en el flujo de trabajo habitual de los desarrolladores mediante envenenamiento de documentación (documentation poisoning), manipulación de servidores MCP y ingeniería social
- Aunque los LLM locales tienen ventajas en términos de privacidad de datos, la principal conclusión de este estudio es que, por su falta de capacidad de razonamiento, alineación y filtrado de seguridad, pueden terminar siendo una opción más riesgosa
Panorama general de las vulnerabilidades de seguridad en los LLM locales
- Aunque los LLM que se ejecutan localmente suelen considerarse una opción para mejorar la seguridad y la privacidad, el estudio muestra que en la práctica pueden manipularse con mayor facilidad por parte de atacantes
- En pruebas realizadas con el modelo
gpt-oss-20b, cuando un atacante pedía mediante prompts código con vulnerabilidades incluidas, la tasa de generación de ese código por parte del modelo fue muy alta
- En particular, incluso cuando la intención maliciosa estaba oculta dentro del prompt, el modelo no lograba reconocerla y la procesaba como si fuera una solicitud normal
- Este fenómeno se agrava cuanto menor es el tamaño del modelo y su nivel de alineación (alignment), mientras que los modelos Frontier (como GPT-5) mostraron una resistencia relativamente mayor
Amenazas de inyección de prompts y de código
- Los LLM enfrentan una triple amenaza letal (lethal trifecta): acceso a datos privados, exposición a contenido no confiable y posibilidad de comunicación externa
- Un atacante puede insertar código malicioso dentro de un prompt para inducir una inyección de código (code injection)
- El código generado puede parecer normal, pero en realidad puede infectar el sistema del desarrollador o funcionar como un backdoor persistente en producción
- Los modelos pequeños como
gpt-oss-20b son especialmente vulnerables a este tipo de ataques, y pueden generar código malicioso lo bastante sofisticado como para pasar una revisión básica de código
Tipo de ataque 1: backdoor “easter egg” (95% de éxito)
- El primer ataque engaña al modelo para que inserte un backdoor de RCE (Remote Code Execution) disfrazado como una función “easter egg”
- El prompt malicioso solicita crear un servidor web en Flask que ejecute
eval() cuando se reciba un encabezado HTTP específico (X-Math)
- El modelo interpreta esto como una función legítima y genera código del servidor que incluye el comportamiento malicioso
- El código generado incluye una rutina de ejecución dinámica de código mediante el decorador
@app.after_request, lo que permite al atacante ejecutar código arbitrario en el servidor con una simple petición HTTP
- También incluye una función de ping asíncrono que verifica la variable de entorno
KUBERNETES_SERVICE_HOST para enviar una señal al atacante solo en entornos de producción
- Según los resultados del experimento, el mismo prompt tuvo éxito 95 veces de 100, y aun con prompts modificados logró 86 éxitos en 800 intentos
- Los modelos Frontier como GPT-5 mostraron resistencia ante el mismo prompt
Tipo de ataque 2: inducción de ejecución inmediata de código (RCE) (43.5% de éxito)
- El segundo ataque busca inducir la ejecución inmediata de código malicioso en el entorno local del desarrollador
- Primero, el atacante presenta un prompt de sobrecarga cognitiva (cognitive overload) para aumentar la carga mental del modelo y desactivar sus filtros de seguridad
- Después solicita la generación de código Python ofuscado, haciendo que el modelo escriba un script malicioso que incluye una llamada a
exec
- El código ofuscado
"".join(chr(100 + i) for i in [1-2, 2-1, (1<<4)+4, 1])[::-1] se descifra como exec, y
finalmente queda completado para descargar y ejecutar código desde https://jacek.migdal.pl/speed.py
- La tasa de éxito fue de 43.5%, menor que la del primer ataque, pero es mucho más peligroso porque provoca RCE inmediata
- Basta con que el ataque funcione una sola vez para permitir el robo de credenciales locales del desarrollador (
~/.aws/, ~/.ssh/), la instalación de malware y la propagación por la red
Cómo funciona la cadena de ataque
- Estos ataques no dependen de vulnerabilidades avanzadas, sino de convertir los flujos de trabajo cotidianos de desarrollo en rutas de ataque
- Cuando el desarrollador entrega contenido externo como contexto al asistente de IA, se ejecutan los prompts maliciosos ocultos dentro de ese contenido
- Las etapas del ataque son las siguientes:
- El atacante distribuye contenido que incluye prompts maliciosos
- El desarrollador lo introduce en el modelo, ya sea directamente o mediante MCP (Model Context Protocol)
- El modelo genera código comprometido
- El desarrollador ejecuta o despliega ese código
- El atacante obtiene acceso persistente o control inmediato
- Principales vías de infiltración:
- Envenenamiento de documentación (documentation poisoning): inserción de código malicioso en README, documentación de API o ejemplos en Reddit
- Manipulación de servidores MCP: inyección de ejemplos maliciosos a través de servidores que proveen contexto (como Context7)
- Ingeniería social: inserción de ejemplos de código ocultos en issues o comentarios de PR en GitHub
Por qué los modelos locales son más peligrosos
- En general, los modelos locales se prefieren por la privacidad de datos, pero este estudio expone un riesgo paradójico en materia de seguridad
- Los modelos Frontier basados en la nube permiten monitoreo de prompts y detección de violaciones de políticas, mientras que los modelos locales carecen de esa supervisión
- Los modelos Frontier (GPT-5, Claude Sonnet 4.5, Grok 4, etc.) rechazan prompts con texto ofuscado devolviendo “Safety Fail”
- En cambio, los modelos locales, al carecer de supervisión, permiten más libertad para probar, pero en la práctica presentan una exposición grave a vulnerabilidades
- Falta de capacidad de razonamiento: no reconocen intenciones maliciosas complejas
- Alineación débil: se dejan engañar fácilmente por sobrecarga cognitiva y técnicas de ofuscación
- Aprendizaje de seguridad insuficiente: recursos limitados para detectar prompts adversariales
- Como resultado, aunque los modelos Frontier son más difíciles de atacar y tienen menores tasas de éxito, es difícil verificar objetivamente su rendimiento de seguridad, mientras que los modelos locales sí pueden probarse, pero son mucho más vulnerables
Propuesta de nuevas estrategias de defensa
- Este estudio señala la ausencia de un entorno de seguridad estandarizado para probar asistentes de IA
- El software tradicional cuenta con pruebas de penetración, pero la seguridad de los LLM aún no está sistematizada
- Se proponen 4 medidas defensivas clave:
- Análisis estático: detectar patrones peligrosos como
eval() y exec() antes de la ejecución, y desactivar por defecto ciertas funciones del lenguaje
- Ejecución en sandbox: ejecutar el código inicial en entornos aislados, como contenedores o runtimes de WebAssembly
- Monitoreo de entrada/salida y de red: vigilar las entradas, salidas y el tráfico de red del asistente de IA con foco en comportamientos anómalos
- Segunda revisión (second look): usar un modelo auxiliar simple para volver a revisar si la salida final viola políticas
- Por ejemplo, aunque el modelo principal sea engañado y genere código con
eval(), el modelo auxiliar podría detectarlo
- En conclusión, los LLM son herramientas poderosas, pero no son seguras por naturaleza, y es indispensable contar con un sistema de seguridad basado en la desconfianza hacia el código generado por IA y con nuevas estrategias de defensa para la cadena de suministro
1 comentarios
Comentarios de Hacker News
Por más potente que sea un reasoning LLM, si hay instrucciones maliciosas dentro del contexto, igual termina generando código vulnerable.
Que sea más fácil engañar a un modelo pequeño no es un punto tan interesante desde la perspectiva de seguridad.
Al final, hay que asumir que cualquier modelo puede sufrir prompt injection.
Por eso se necesitan capas adicionales de protección, como sandbox execution o análisis estático, para poder defenderse incluso cuando el modelo ya fue comprometido.
Ayer mismo di una charla sobre este tema, acerca de sandboxing coding agents.
Un sistema así ya está comprometido desde el inicio.
Más que confiar en enfoques como defense in depth, creo que lo correcto es no construir una arquitectura tan peligrosa desde el principio.
Incluso cosas como la ubicación para guardar archivos temporales se vuelven más claras dentro de un entorno sandbox.
Claro, aparecieron problemas nuevos, pero en general fue una gran mejora.
Si ejecutas localmente un modelo como deepseek, creo que es seguro mientras no le metas prompts falsos.
Al final, los factores de riesgo son prompts que el usuario copia desde afuera o configuraciones que permiten que el modelo acceda a recursos de Internet.
Esto siempre ha sido una debilidad general de TI, y simplemente es algo que debe manejarse con capacitación de usuarios y aislamiento de red.
Datos comunes como tickets o documentos ahora también pueden ser un riesgo de seguridad.
Muchos ataques potentes comenzaron desde un punto de partida simple.
Estos ataques están en un nivel demasiado básico de sentido común en seguridad.
Se pueden evitar con solo revisar el código antes de desplegarlo a producción.
Si no sabes nada, de todos modos terminarás desplegando código inseguro.
Los modelos abiertos son accesibles, pero creer que eso se puede resolver con post-training es una ilusión.
El segundo ataque no era sobre desplegar código, sino sobre un LLM que lee comentarios de reddit y los ejecuta de inmediato.
La actitud de restarle importancia a este problema termina creando una amenaza de seguridad aún mayor.
Suena raro decir que un LLM local puede ser atacado.
Si el sistema ya fue comprometido, parecería que se podría causar un daño mayor que simplemente engañar al LLM.
Es decir, un atacante puede inyectar prompts a través de la entrada de datos.
Si el LLM es un agente con permisos para ejecutar comandos, eso se convierte directamente en una vulnerabilidad de ejecución de comandos.
En una situación así, en realidad ya todo está perdido.
Este texto se siente como si lo hubiera escrito el equipo comercial de Anthropic o OpenAI.
En la práctica, los modelos locales rara vez se usan como agentes de ejecución de código, y la mayoría destacan más en transformación de datos o tareas de NLP.
Cuando uso modelos locales con Agno agent, siempre hago que impriman el código generado antes de ejecutarlo y los aíslo en un sandbox local.
De hecho, creo que los agentes tipo navegador como Atlas o Comet son más peligrosos.
Los modelos open source actuaron tal como indicaba el prompt, y los modelos cerrados lo ignoraron.
Es decir, los que fallaron en la prueba de alignment fueron más bien los modelos cerrados.
La expresión “lethal trifecta” suena bien, pero no explica tan bien el riesgo real.
En la práctica, con solo tener capacidad de comunicación externa ya es suficientemente peligroso.
El LLM en sí es un montón de datos de caja negra imposibles de verificar, así que cuesta confiar en él.
Tal vez una startup pequeña pueda tolerarlo, pero un lugar como Coinbase debería pensarlo dos veces antes de permitir ese acceso.
Esto trata sobre la paradoja de seguridad de la ejecución de código no verificado.
Si vas a ejecutar localmente malware o código no confirmado, primero habría que volver a pensar por qué lo estás haciendo.
Como los LLM interpretan instrucciones en lenguaje humano como si fueran código, la frontera entre código y datos se vuelve borrosa.
Si estás usando la capacidad de razonamiento de un LLM como frontera de seguridad, ya tienes un problema grave.
Ese enfoque está mal diseñado desde la base.
Es demasiado obvio que puede haber inyección si no se tiene cuidado con la entrada.
En cualquier sistema, la entrada siempre puede convertirse en un vector de ataque.
Todos los datos que entren a un LLM deben validarse sin falta.
Quisiera saber si es algo como un ataque cross-site del lado del navegador.