El chatbot de 1,25 M£: cuando el proveedor no sabe dónde corre su propio software

El 13 de noviembre de 2020 la ICO multó a Ticketmaster UK con 1,25 M£ por no implementar medidas de seguridad apropiadas. El vector fue un chatbot de atención al cliente de un tercero que Ticketmaster había insertado en varias páginas de su web — incluida la de pago. El detalle más revelador de todo el caso: el proveedor no sabía que su script corría allí.

Un tercero dentro de la página de pago

El chatbot era de Inbenta Technologies: JavaScript alojado en los servidores del propio proveedor, diseñado para leer la pregunta del cliente y sugerir artículos de ayuda. Ticketmaster lo consideró parte crítica del customer journey y lo desplegó en varias páginas, incluida la de pago — donde no cumplía ninguna función de pago. Inbenta declaró después que no se le informó de que el script se aplicaría a la página de pago y que lo habría desaconsejado.

En febrero de 2018 el grupo Magecart comprometió los servidores de Inbenta y modificó ese script, añadiéndole un skimmer. Ticketmaster no cambió nada: su página siguió descargando y ejecutando el fichero del proveedor exactamente igual que siempre — solo que ahora llegaba envenenado, y cada visitante recibía la versión contaminada de forma automática.

Cómo llega un chat a un número de tarjeta

Primero, el malentendido que conviene desactivar: el ataque no entró por el cuadro de texto del chat. Nadie «habló» con el chatbot para hackearlo. La puerta estaba en otro sitio — y era una decisión de arquitectura, no un agujero clásico.

Cuando una página ejecuta un script, ese script corre con los mismos privilegios que el código propio de la página. No hay muro por defecto: un script cargado en la página de pago puede leer cualquier campo del formulario, escuchar cada pulsación de teclado y enviar datos a cualquier servidor del mundo. El navegador no distingue «script de Ticketmaster» de «script del proveedor» — técnicamente, ambos son la página.

Así que la puerta no es el cuadro del chat. La puerta es la etiqueta <script> apuntando a un servidor que no controlas. La ICO consideró ese riesgo notorio: ENISA y el NCSC llevaban años advirtiendo del JavaScript de terceros en páginas de pago.

Nueve semanas de ceguera

Entre febrero y abril de 2018 los bancos empezaron a reportar fraude asociado al sitio: Monzo notificó a Ticketmaster en abril, y también llegaron señales de Barclaycard, Mastercard, American Express y Commonwealth Bank of Australia. Incluso con esos avisos encima de la mesa, Ticketmaster tardó nueve semanas en empezar a monitorizar el tráfico de red de su propia página de pago. El código malicioso se identificó y desactivó el 23 de junio de 2018 — a su favor, de inmediato tras identificarlo, notificando a la ICO y a los afectados ese mismo día.

• 9,4 M

  interesados del EEE notificados como potencialmente afectados (1,5 M en Reino Unido)

• 60.000 + 6.000

  tarjetas de Barclays con fraude constatado, más tarjetas reemplazadas por Monzo de forma preventiva

• 9

  semanas desde los avisos de los bancos hasta monitorizar la página de pago

Qué sancionó realmente el regulador

La sanción se apoya en los artículos 5(1)(f) y 32 del RGPD — integridad y confidencialidad, y seguridad del tratamiento. Aunque el ataque comenzó en febrero de 2018, el periodo sancionado va solo del 25 de mayo al 23 de junio de 2018, ya con el RGPD en vigor. Los hallazgos se leen menos como una historia de hackers y más como una auditoría de gobernanza ausente:

• →Sin análisis de amenazas documentado para scripts de terceros en páginas que tratan datos personales.
• →Sin visibilidad de qué cambiaba en el script, ni cuándo.
• →Proveedor evaluado en 2013 y de nuevo en 2018 — una cadencia de revisión que la ICO consideró demasiado larga.
• →El chatbot estaba conectado al entorno del titular de la tarjeta, por lo que le aplicaba PCI-DSS.
• →Mitigaciones estructurales disponibles y no aplicadas: alojar el script en local, una Content Security Policy o un iframe.

Esas tres mitigaciones merecen leerse por lo que son: política aplicada por arquitectura y no por confianza. Servir tu propia copia congelada del script significa que un cambio no autorizado nunca llega a producción. Una CSP es una lista blanca determinista — aunque el skimmer se ejecute, el navegador bloquea la exfiltración. Un iframe aísla el widget para que no pueda leer el formulario en absoluto.

La defensa que fracasó

La ICO reprochó a Ticketmaster lo que llamó una confianza indebida en las obligaciones contractuales de seguridad del proveedor, sin pasos propios, suficientes y a tiempo. Y rechazó de plano el argumento de que la culpa fuera de los atacantes o del proveedor: ser víctima de un delito no exime del deber de seguridad, y externalizar no transfiere la responsabilidad.

El contrato no es un control. La observación tardía no es enforcement.

Con precisión: un DPA del artículo 28 es necesario. Simplemente no es suficiente por sí solo — documenta una obligación, no detiene un byte. Ticketmaster recurrió alegando que el ataque era un delito imprevisible contra su proveedor; el recurso quedó suspendido en abril de 2021 a la espera de una acción colectiva paralela de en torno a un millar de clientes. En 2022 la compañía llegó a un acuerdo con esos clientes sin admisión de responsabilidad y, tres meses después, retiró el recurso y pagó íntegra la multa de 1,25 M£. La prensa del sector cifró el coste de gestión del incidente en unos 4 M£ adicionales.

Léelo como un checklist de 2026

Un chatbot de 2018 no es un agente de IA, y no vamos a fingir lo contrario. Pero la analogía se sostiene donde importa: software de un tercero, con lógica propia, actualizable en remoto, ejecutándose dentro del perímetro de datos sensibles del negocio. Sustituye chatbot.js por un tool de MCP, un nodo comunitario de n8n o una dependencia de un agente, y el diagrama es idéntico — salvo que un agente moderno además actúa, no solo lee.

1. 01¿Sabes qué automatizaciones de terceros corren, y dónde? (descubre)
2. 02¿Sabes qué datos tocan y qué riesgo supone? (clasifica)
3. 03¿Su acceso está limitado de forma estructural, no contractual? (gobierna)
4. 04¿Puedes demostrar qué versión corría, cuándo cambió y qué hizo? (documenta)

Esas cuatro preguntas no son un post-mortem de 2020: son lo que pide NIS2 en seguridad de la cadena de suministro y gestión de activos, lo que pide DORA en riesgo TIC de terceros, y lo que llevan pidiendo los artículos 5(1)(f), 28 y 32 del RGPD desde 2018. Lo incómodo de este caso no es que Ticketmaster suspendiera el examen. Es que la mayoría de las empresas que despliegan automatizaciones hoy no podrían responder a la pregunta 01.