El chatbot de Eurostar tenía fallos: prompt injection, IDs flojos y hasta HTML injection

CURIOSIDADES · VIRAL · CIBERSEGURIDAD

1. Qué se descubrió en el chatbot de Eurostar (versión humana, sin humo)

Investigadores de seguridad analizaron el chatbot público de Eurostar y encontraron cuatro problemas que, combinados, permitían manipular la conversación y el contenido mostrado. El punto clave es este: no era “solo un chat”. Era una pieza de software con estados, IDs, reglas y una interfaz que renderizaba resultados.

Eurostar defendió que la información de clientes estaba protegida detrás de login y que el bot no estaba conectado a una base de datos sensible en el momento del hallazgo. Perfecto. Pero aquí va la razón por la que esto se hizo viral: mucha gente lanza el chatbot “para probar” y lo conecta “más tarde”. Y “más tarde” es cuando los fallos pasan de feos a peligrosos.

2. Fallo #1: guardrails que parecían fuertes… pero solo ataban el último mensaje

Un guardrail típico intenta filtrar entradas y salidas: bloquear instrucciones raras, contenido malicioso, peticiones de secretos, etc. En este caso, el sistema daba sensación de “controlado”, pero el detalle técnico fue demoledor: la verificación se aplicaba de forma robusta al último mensaje, mientras que el historial podía llegar al servidor con menos garantías.

¿Traducción? Puedes mandar un último mensaje inocente para “pasar el corte” y, al mismo tiempo, introducir cambios en mensajes anteriores (dentro del contexto) que el modelo sí verá. Es el típico problema de confiar en el cliente. Y en chatbots pasa muchísimo, porque el historial de conversación es “solo texto”… hasta que no lo es.

3. Fallo #2: prompt injection para filtrar instrucciones internas (y guiar el comportamiento)

La prompt injection no suena a vulnerabilidad “web clásica”, pero en la práctica se parece mucho a esto: consigues que el sistema trate datos como instrucciones. Un atacante mete texto que intenta saltarse reglas, extraer prompts internos o forzar al modelo a seguir una “nueva política” dentro de la conversación.

En el caso de Eurostar, el riesgo no era “que el modelo se vuelva loco”, sino que se le podía empujar a revelar piezas internas (como prompts del sistema) o a actuar como si ciertas reglas no existieran. Y una vez conoces la lógica interna, diseñar ataques repetibles se vuelve mucho más fácil.

Si quieres una guía práctica para entender por qué esto no se arregla solo “con un filtro”, te dejo esta pieza que encaja perfecto con el tema: cómo funciona la prompt injection y qué defensas sí tienen sentido.

4. Fallo #3: IDs flojos (conversation_id y message_id) y el clásico “confío en lo que me mandas”

Este es el fallo más aburrido… y por eso es el más peligroso: el cliente manda IDs (de conversación, de mensajes) y el servidor los acepta con controles insuficientes. Cambias un valor, inventas otro, alteras el orden, y el backend sigue como si nada.

En un chatbot, los IDs no son “decoración”. Son lo que separa tu conversación de la de otra persona, lo que evita replays, lo que impide que un chat “heredado” se convierta en una autopista a información que no toca.

Y aquí viene la trampa: muchas empresas están migrando de “chat que responde” a “chat que hace cosas”. Si en esa transición no tienes bien cerrados IDs, autorización y trazabilidad, el salto a agente es una ruleta. Si estás justo en ese punto, esto te interesa: agentes de IA, tool misuse y por qué el riesgo cambia de nivel.

5. Fallo #4: HTML injection (self-XSS) cuando el chatbot devuelve HTML y la UI lo renderiza sin sanitizar

Esta es la parte que más rápido entiende cualquiera: si el chatbot puede devolver HTML (por ejemplo, para mostrar enlaces bonitos) y tu interfaz lo pinta tal cual, acabas con una situación tipo XSS. Y si además alguien logra influir al modelo con prompt injection, ya tienes el combo perfecto para que el bot “te escriba” HTML malicioso.

A veces se queda en self-XSS (se ejecuta en el navegador del propio usuario que lo ve), pero incluso eso es un problemón en soporte: phishing, enlaces falsos, pantallas que imitan login, capturas de sesión si hay más grietas alrededor… y, sobre todo, pérdida de confianza.

6. El patrón que se repite (y por qué te debería importar aunque “no haya datos”)

La mayoría de empresas no se la juegan el primer día. Empiezan con un bot de FAQs: horarios, política de cambios, estado de una línea… y poco más. El problema es lo que pasa después: el bot empieza a consultar pedidos, a abrir tickets, a hacer cambios, a verificar identidades.

En ese momento, un fallo que parecía “solo una curiosidad” se transforma en un fallo operativo. Y si además tienes un equipo estresado por sacar funcionalidades rápido, los atajos se acumulan: “ya sanitizaremos luego”, “ya pondremos permisos luego”, “esto es solo un MVP”.

7. Checklist práctico: cómo montar un chatbot de soporte sin regalarte

Si mañana tuvieras que lanzar un chatbot en tu empresa, este sería mi mínimo de seguridad (sin postureo, cosas que realmente cortan cadenas de ataque):

• La UI no manda el “contexto de verdad”. El servidor reconstruye el historial desde su storage, o firma y revalida todo el paquete. Nada de “confío en lo que me envías”.
• IDs ligados a autorización. conversation_id y message_id deben estar atados a usuario/sesión y a reglas claras. Si no hay vínculo, el backend rechaza.
• Salida del modelo en formato seguro. Si quieres enlaces, usa datos estructurados (título + URL en allowlist) y que el frontend genere el HTML. Nunca “HTML crudo del modelo”.
• Reduce el impacto de la prompt injection. Asume que ocurrirá: limita herramientas, aplica permisos por acción, añade confirmaciones y separa “responder” de “ejecutar”.
• Monitoriza lo raro. Alertas por patrones anómalos: cambios de IDs, contenido con tags HTML, intentos repetidos, respuestas fuera de dominio, etc.
• Kill switch. Poder degradar a “solo FAQs” en minutos, sin derribar el soporte cuando algo se tuerce.

Y si quieres llevar esto a un terreno “de empresa” (políticas, trazabilidad, responsabilidades), te va a venir bien tenerlo documentado como Dios manda: cómo documentar el uso de IA en una empresa.

8. Las 6 preguntas que deberías hacer antes de poner un chatbot en producción

Esto te sirve tanto si lo estás desarrollando tú como si lo compras a un proveedor. Si alguna respuesta es “ya lo veremos”, mala señal:

• ¿El servidor reconstruye el historial o acepta el que manda el cliente?
• ¿Cómo se valida que ese conversation_id pertenece al usuario correcto?
• ¿El bot devuelve HTML o solo datos estructurados?
• ¿Qué pasa si el modelo intenta “saltarse” reglas por prompt injection? ¿Cuál es el plan de contención?
• ¿Hay logs y alertas específicas para IA (contenido sospechoso, picos de uso, herramientas invocadas)?
• ¿Existe un plan de respuesta rápida (desactivar, parchear, comunicar) sin improvisar?

9. Cierre: lo incómodo de este caso es que podría ser cualquier empresa

El “caso Eurostar” no es interesante porque sea Eurostar. Es interesante porque mezcla tres ingredientes que están por todas partes: un LLM, una UI que quiere verse moderna y una API con decisiones rápidas.

Si estás metiendo IA en atención al cliente, quédate con esta idea: no gana el que tiene el modelo más listo, gana el que lo pone dentro de un perímetro seguro. Y eso sigue siendo ingeniería clásica: validación, autorización, sanitización, observabilidad y capacidad de apagar.

Fuentes externas (lectura recomendada): TechRadar y Pen Test Partners.