Plugins de chatbot web: cómo los widgets inseguros amplifican la inyección de prompts
Un estudio de IEEE S&P 2026 sobre 17 plugins de chatbot en más de 10.000 sitios revela historiales de conversación falsificables (inyecciones 3 a 8 veces más fuertes) y herramientas de scraping que mezclan contenido fiable y no fiable.
¿Qué es esto?
La investigación sobre inyección de prompts suele apuntar a los asistentes más avanzados: copilotos, agentes de código, pipelines RAG. Pero la aplicación de LLM más común en la web es mucho más simple: la burbuja del chatbot de atención al cliente en la esquina de un sitio de comercio o SaaS. Un artículo titulado «When AI Meets the Web: Prompt Injection Risks in Third-Party AI Chatbot Plugins», enviado a arXiv el 8 de noviembre de 2025 y aceptado en IEEE S&P 2026, es el primer análisis a gran escala de esa superficie. Firmado por Yigitcan Kaya, Anton Landerer, Stijn Pletinckx, Michelle Zimmermann, Christopher Kruegel y Giovanni Vigna (UC Santa Barbara), estudia 17 plugins de chatbot de terceros desplegados en más de 10.000 sitios web públicos y demuestra que es la fontanería que rodea al LLM —y no el modelo en sí— donde falla la seguridad.
Cómo funciona
Estos plugins actúan como intermediarios entre un creador de sitios no experto y una API comercial de LLM. El estudio documenta dos debilidades estructurales.
La primera es la integridad del historial de conversación. En un chat normal, cada solicitud al LLM reenvía los turnos anteriores para aportar contexto. Los investigadores hallaron que 8 plugins (usados en unos 8.000 de los sitios estudiados) confían en el historial enviado por el navegador sin verificarlo en el servidor. Un atacante que controla su propia sesión puede editar esa carga útil antes de que salga del navegador: falsificando respuestas previas del asistente e incluso mensajes de sistema falsos que el modelo trata como autoritativos. Con un historial fabricado que afirma que el asistente ya aceptó abandonar sus reglas, una inyección directa se vuelve mucho más eficaz: el artículo midió un aumento de 3 a 8 veces en el éxito de provocar comportamientos no deseados, como la generación de código.
La segunda es la mezcla de contenido no fiable. 15 de los 17 plugins ofrecen herramientas —el scraping web en particular— para enriquecer el contexto del chatbot con contenido del sitio. Pero no distinguen entre el contenido fiable que controla el propietario (descripciones de producto, políticas) y el contenido de terceros no fiable (reseñas de clientes, preguntas y respuestas, comentarios). Todo lo que se extrae llega al prompt con la misma autoridad, lo que constituye el escenario clásico de la inyección de prompts indirecta: una reseña maliciosa puede llevar instrucciones que el chatbot luego ejecuta. Los autores encontraron que alrededor del 13 % de los sitios de comercio electrónico estudiados ya habían conectado sus chatbots a contenido de terceros, exponiendo la superficie antes incluso de que aparezca un atacante.
Por qué importa
La conclusión es que las salvaguardas de los LLM no sobreviven a una mala integración. Los modelos comerciales subyacentes vienen con alineación y entrenamiento de rechazo, pero un plugin inseguro entrega a los atacantes las palancas —historial falsificado, contexto sin segmentar— que rodean esas defensas. Como el mismo puñado de plugins se reutiliza en miles de sitios, un solo patrón inseguro se multiplica en una larga cola de despliegues vulnerables, gestionados por propietarios que no escribieron ni una línea de la integración. Es el medio del mercado, poco glamuroso: no un agente estrella, sino el chatbot que los usuarios corrientes realmente tocan.
Defensas
Imponga la integridad del historial en el servidor. Nunca confíe en el historial de mensajes (y menos en los roles de sistema o asistente) reproducido desde el cliente. Reconstruya o autentique la sesión en el servidor, firme o almacene la transcripción canónica, y rechace de plano cualquier mensaje de sistema suministrado por el cliente. Este único control elimina la amplificación de 3 a 8 veces que midió el artículo.
Separe el contenido fiable del no fiable en el prompt. Trate las reseñas extraídas, los comentarios y cualquier texto de terceros como datos, no como instrucciones. Delimítelos con separadores claros, etiquete su procedencia y —cuando el plugin lo permita— aplique spotlighting o un filtro de entrada antes de que lleguen al modelo. El contenido controlado por el propietario y el controlado por los visitantes no deben compartir el mismo nivel de autoridad. Esto se corresponde directamente con las recomendaciones de OWASP LLM01: Prompt Injection.
Limite el radio de impacto. Dé al chatbot la mínima capacidad necesaria: sin llamadas a herramientas, ejecución de código ni acceso a datos sensibles que no requiera para el soporte. Añada filtrado de salidas de alto riesgo (código, enlaces, comandos) y vigile las invocaciones de herramientas anómalas en lugar de confiar en el rechazo del modelo.
Si opera un sitio con uno de estos widgets, revise si su chatbot extrae contenido generado por usuarios y pregunte a su proveedor cómo se valida el historial de conversación. La corrección está en la capa de integración, justo donde la mayoría de los propietarios asume que el proveedor ya lo tiene cubierto.
Estado
| Elemento | Detalle |
|---|---|
| Fuente | arXiv:2511.05797, «When AI Meets the Web», enviado el 2025-11-08; en IEEE S&P 2026 |
| Alcance | 17 plugins de chatbot de terceros en más de 10.000 sitios web públicos |
| Hallazgo 1 | 8 plugins (~8.000 sitios) sin integridad de historial → inyección directa 3 a 8 veces más fuerte |
| Hallazgo 2 | 15 plugins mezclan contenido fiable/no fiable mediante herramientas → inyección indirecta; ~13 % de los sitios de comercio electrónico ya expuestos |
| Causa raíz | Prácticas de integración inseguras, no el LLM subyacente |
| Acción | Integridad de historial en el servidor; separación de contenido fiable/no fiable; chatbots de capacidad mínima |