Explotación de la confianza (LLM09 Misinformation)
Por qué la seguridad de un LLM incluye la confianza de quien lo usa: alucinaciones convertidas en ataque (slopsquatting de paquetes), casos reales de exceso de confianza y cómo diseñar procesos que verifiquen en lugar de creer.
Los LLM responden con texto fluido, seguro y bien estructurado, aunque no sepan la respuesta. Y las personas tendemos a creer lo que suena seguro. Esa combinación abre una vulnerabilidad que no está en el código ni en la red: está en la confianza del usuario.
En el OWASP Top 10 for LLM es LLM09:2025: Misinformation. Su idea central: una alucinaciónAlucinaciónSalida de un LLM que suena plausible y segura pero es falsa o inventada, como una cita, una cifra o el nombre de un paquete que no existe. deja de ser solo un problema de fiabilidad cuando alguien puede provocarla, predecirla o explotarla contra los usuarios. Y esa explotación se llama trust exploitation o manipulación de personas a través de la IA: el atacante no rompe el modelo, usa la fe que le tienen.
Por qué la confianza es una superficie de ataque#
- La forma no delata el fondo. Una respuesta inventada tiene la misma redacción que una correcta. No hay un tono de duda que avise.
- Sesgo de automatización. Tendemos a aceptar la sugerencia de un sistema automático, sobre todo bajo prisa y cuando contradecirla cuesta esfuerzo.
- Verificar cuesta. Comprobar un dato lleva tiempo; creerlo es gratis. Si el flujo no obliga a verificar, no se verificará.
- Predecibilidad. Un modelo tiende a inventar las mismas cosas ante las mismas preguntas. Lo que un modelo se inventa de forma estable es una superficie que un atacante puede estudiar.
El caso estrella: alucinación de paquetes#
Un desarrollador pide a su asistente de código una librería para tarea X. El modelo recomienda secure-utils-xtools, un paquete que no existe. Un atacante que haya detectado que el modelo sugiere ese nombre con frecuencia puede registrarlo en PyPI o npm con malware dentro. A partir de ese momento, el nombre inventado existe, y todo el que siga la recomendación lo instalará.
Es el slopsquattingSlopsquattingRegistrar en un repositorio público el nombre de un paquete que un LLM suele inventar, para que quien siga su recomendación instale malware. (término de Seth Larson, de la Python Software Foundation): como el typosquatting, pero apostando a lo que el modelo se inventa y no a lo que el usuario teclea mal.
Paso 1 de 6El atacante sondea
El atacante hace al modelo las mismas preguntas de programación cientos de veces y anota los paquetes que recomienda y NO existen. «secure-utils-xtools» sale en 7 de cada 10 respuestas: una trampa estable.
- Sondeo. El atacante hace al modelo (o a varios) cientos de preguntas de programación realistas y recopila los paquetes inexistentes que recomienda. Se queda con los que se repiten.
- Registro. Publica uno de esos nombres en el registro público, con un README convincente, a veces con funcionalidad real para no levantar sospechas, y código malicioso (robo de secretos, reverse shell, persistencia).
- Espera. No necesita convencer a nadie: el propio asistente de la víctima hace el trabajo de marketing.
- Instalación. El desarrollador (o un agente de código que ejecuta comandos solo) instala el paquete. Se ejecutan los scripts de instalación y, después, el código importado, con los permisos del desarrollador o del entorno de CI.
Lo que se sabe sobre su alcance, con las cautelas de que son estudios y no mediciones de ataques reales:
- Un estudio académico (Spracklen et al., USENIX Security 2025) generó cientos de miles de ejemplos de código con múltiples modelos y encontró que alrededor de uno de cada cinco paquetes recomendados no existía, con tasas mucho mayores en modelos abiertos que en los comerciales, y con muchos nombres inventados que se repetían entre ejecuciones, es decir, explotables.
- Un investigador de Lasso Security (2023) publicó un paquete vacío con un nombre que modelos de código inventaban (
huggingface-cli) y registró decenas de miles de descargas en pocos meses, a la vez que su nombre aparecía en repositorios de proyectos reales.
No solo paquetes: otros casos reales#
La misma dinámica aparece donde sea que alguien actúe por lo que dijo un modelo:
| Caso | Qué pasó | Lección |
|---|---|---|
| Citas legales inventadas | Abogados presentaron escritos con jurisprudencia que un chatbot se había inventado (Mata v. Avianca, 2023) | Quien firma responde del contenido, aunque lo haya escrito la IA |
| Chatbot de aerolínea | Un tribunal canadiense responsabilizó a Air Canada de lo que dijo su chatbot sobre tarifas de duelo (Moffatt v. Air Canada, 2024) | La empresa responde de lo que dice su asistente, no vale «es solo un bot» |
| Código inseguro | Un asistente sugiere un patrón vulnerable (SQL concatenado, credenciales en código) con total naturalidad | El código generado hay que revisarlo como código de un tercero |
| Manipulación deliberada | Un atacante envenena fuentes o la memoria para que el modelo diga lo que él quiere (envenenamiento de memoria) | La desinformación puede ser provocada, no solo accidental |
Defensa: verificar, no creer#
OWASP propone, para LLM09, combinar mejor información en el modelo, comprobaciones automáticas y supervisión humana. Traducido a prácticas:
- Verifica antes de instalar. Que el paquete exista no basta. Comprueba antigüedad, número de descargas, mantenedores y que el repositorio enlazado sea real y coincida con lo esperado.
- Registro intermedio con lista de permitidos. Un proxy privado (por ejemplo, AWS CodeArtifact con repositorios aguas arriba controlados) que solo sirva paquetes aprobados. Un paquete nuevo y desconocido no se instala sin revisión.
- Fija versiones y hashes. Lockfiles y
pip install --require-hashesimpiden que un paquete cambie bajo tus pies. - Revisa las dependencias nuevas en el PR. Un cambio que añada una dependencia pide una revisión explícita, y los asistentes de código no deben poder añadirla sin ella.
- Entornos de ejecución aislados. Si un agente instala paquetes, que sea en un sandbox sin secretos ni red amplia (guardrails y sandbox).
- Ancla las respuestas en fuentes. RAG con fuentes verificadas y citas comprobables reduce la invención, aunque no la elimina.
- Comprobaciones automáticas. Validar que las citas, enlaces, paquetes y cifras existen antes de mostrarlos.
- Supervisión humana en decisiones de impacto. Todo lo que sea legal, médico, financiero o de seguridad lo revisa una persona con competencia, no quien lo pidió con prisa.
- Comunica la incertidumbre en la interfaz. Avisos, niveles de confianza, enlaces a las fuentes y un botón para ver de dónde sale cada dato.
- Formación específica. Que el equipo sepa que la fluidez no es evidencia y qué verificar en cada tipo de salida.
- Fricción donde importa. Un paso obligatorio de revisión justo antes de lo irreversible (instalar, desplegar, enviar, pagar).
- Cultura de duda. Preguntar «¿de dónde sale esto?» debe ser normal, no una molestia.
- Responsabilidad clara. Quien actúa sobre una respuesta de la IA es responsable de haberla comprobado.
Un ejemplo de comprobación mínima antes de instalar una dependencia sugerida:
PKG="$1"
# ¿Existe y qué historial tiene? (PyPI JSON API)curl -s "https://pypi.org/pypi/${PKG}/json" \ | jq '{nombre: .info.name, primera_version: (.releases | to_entries | map(select(.value|length>0)) | .[0].key), resumen: .info.summary, repo: .info.project_urls}'
# Si no existe, o es de hace días y sin repo enlazado: NO instalar, revisar a mano.pip index versions "$PKG"Tu turno
Prueba la alucinación de paquetes en tu entorno
Con un asistente de código que uses y sin instalar nada:
- Haz 20 preguntas del tipo «¿qué librería de Python uso para X?» sobre temas poco comunes (parseo de formatos raros, utilidades de seguridad).
- Extrae los nombres de paquete de cada respuesta y comprueba cuántos no existen en PyPI.
- Repite las preguntas en otra conversación. ¿Los nombres inventados se repiten?
- Escribe una regla para tu CI que falle si un PR añade una dependencia que no está en tu lista de permitidos o es muy reciente.
No registres paquetes con esos nombres ni los publiques: el ejercicio es medir el riesgo, no explotarlo.
Reto
El nombre del paquete que sugirió la IA existe en PyPI. ¿Entonces es seguro?
▸Mostrar solución
No. Que exista no dice nada sobre quién lo publicó ni cuándo. Justo ese es el ataque: el atacante lo registró porque el modelo lo sugiere. Mira antigüedad, descargas, mantenedores, un repositorio real enlazado y que haga lo que dice. Y mejor aún: que solo se pueda instalar lo que ha pasado por tu registro aprobado.
Reto
¿Por qué los modelos comerciales alucinan menos paquetes que los abiertos, y por qué no basta con elegir uno mejor?
▸Mostrar solución
Los modelos grandes y comerciales suelen tener más datos y más ajuste, y alucinan menos nombres, pero no ninguno. Y para el atacante basta con encontrar un solo nombre que se repita. Elegir un modelo con menos alucinaciones reduce el riesgo, no lo elimina: el control tiene que estar en el proceso (verificar y mediar la instalación), no en la esperanza de que el modelo acierte.
En resumen#
- LLM09:2025 trata la desinformación: respuestas falsas con aspecto fiable, y la sobreconfianza de quien las usa.
- Se vuelve un ataque cuando se puede predecir y explotar lo que el modelo se inventa. El ejemplo: slopsquatting, registrar los paquetes que un asistente alucina.
- Es un ataque a la cadena de suministro con la IA como intermediario, y los agentes que instalan solos eliminan la última comprobación humana.
- Defensa: verificar, no creer: registro con lista de permitidos, comprobar antigüedad y reputación, fijar hashes, revisión de dependencias nuevas y sandbox.
- Para decisiones de impacto: fuentes comprobables, supervisión humana y responsabilidad de quien actúa sobre la salida.