Un servidor de analítica sin actualizar llevó un código que roba tarjetas a todas las páginas de pago de Convertr

Entre el 24 y el 27 de octubre de 2026, todas las páginas de pago de Convertr, la plataforma brasileña que gestiona tiendas y cobros de decenas de marcas de moda, cargaron un código diseñado para copiar la tarjeta del comprador. Según el análisis publicado por Sansec, la firma especializada en seguridad de comercio electrónico que lo detectó, el código iba añadido al final del script de analítica Plausible que Convertr alojaba en un servidor suyo. No estaba en la pasarela de pago ni en la plantilla de ninguna tienda.

Sansec señala como vía de entrada más probable un fallo crítico corregido en mayo, aunque no puede confirmarlo. La herramienta, instalada para contar visitas, se ejecutaba en la página de pago con el mismo acceso que el formulario de la tarjeta y llevaba sin actualizarse desde 2025.

¿Cómo llegó un skimmer a la página de pago a través de la analítica?

El skimmer llegó escondido en el fichero de seguimiento de Plausible que Convertr servía, desde analytics.convertr.app.br, a todas las páginas de pago de sus comercios. Un skimmer web es un fragmento de JavaScript que se ejecuta en el navegador del comprador y copia lo que teclea en el formulario de pago, y el sector agrupa estos ataques bajo el nombre de Magecart. Según Sansec, Convertr instaló en 2025 la versión 3.0 de Plausible Community Edition (CE), una alternativa de código abierto a Google Analytics, y no volvió a actualizarla.

¿Por dónde pudieron entrar los atacantes?

Sansec apunta a la CVE-2026-8467, un fallo en una herramienta de desarrollo que Plausible CE dejaba accesible en producción, aunque advierte de que no ha visto los registros del servidor de Convertr. El fallo está en phoenix_storybook, una biblioteca para mostrar y probar componentes de interfaz durante el desarrollo. Según el aviso de seguridad de GitHub, su zona de pruebas (Playground) aceptaba valores enviados por WebSocket sin autenticación y los insertaba sin escapar en una plantilla que después se compilaba y evaluaba sin aislamiento. El resultado es la ejecución de código en el servidor sin credenciales, con una puntuación CVSS v4 de 9,5.

Plausible CE incluía esa biblioteca y la publicaba en la ruta /storybook en las versiones 3.0.0 a 3.2.0. La 3.2.1, publicada el 15 de mayo de 2026, elimina ese punto de acceso, y su nota de seguridad recomienda bloquear /storybook en el proxy inverso a quien no pueda actualizar todavía. El investigador que encontró el fallo lo comunicó en privado el 11 de mayo. La corrección llegó cuatro días después, más de cinco meses antes del ataque.

¿Qué hacía el código inyectado?

El código inyectado copiaba los datos de la tarjeta y el CPF del comprador y los enviaba a un dominio de los atacantes. Conservaba el script original de Plausible y le añadía al final un bloque ofuscado que solo se activaba cuando la dirección de la página contenía el dominio de pago de Convertr. Recogía número de tarjeta, caducidad, CVV, nombre del titular y CPF (el número de identificación fiscal brasileño), tanto de los campos del formulario como de las peticiones a la API de pago. Después codificaba el registro en base64 y lo enviaba a 1x0.is.

La primera versión buscaba los campos con patrones genéricos. Hacia el 26 de octubre apareció otra ajustada a los nombres exactos de la API de pago de Convertr. En nuestra lectura, ese ajuste apunta a un operador que revisaba lo capturado, algo que Sansec no afirma.

¿Hasta dónde se conoce el ataque?

Se conoce bien la cronología técnica, pero no cuántas tarjetas se robaron, y la versión de Convertr choca con la de Sansec.

¿Cuánto tiempo estuvo activo el skimmer?

El skimmer estuvo activo unos tres días, y la caché del navegador pudo alargar su efecto hasta 24 horas más. Sansec registró la última copia limpia del script el 24 de octubre a las 05:03 UTC y detectó el código malicioso ese mismo día a las 23:22. Avisó a Convertr antes de publicar, sin obtener respuesta, y el 26 a las 15:34 UTC, día en que la firma publicó su análisis, la plataforma seguía sirviéndolo. El 27, Convertr comunicó que había retirado el código y actualizado Plausible. A las 13:08 UTC de ese día Sansec confirmó que el fichero volvía a estar limpio.

¿Cuántas tarjetas se robaron?

Nadie ha publicado cuántas tarjetas se capturaron. Según datos de Convertr citados por Sansec, sus comercios han vendido más de 2.000 millones de reales (unos 320 millones de euros) a través de la plataforma. Convertr aseguró a Canaltech que no se accedió a datos sensibles de comerciantes ni de clientes, una postura que choca con el análisis técnico de Sansec, también recogido por BleepingComputer. Ningún informe forense público concilia todavía las dos versiones. Convertr comunicó a Sansec que está avisando a los comercios afectados, a los proveedores de pago y a las autoridades.

¿Hubo otras instalaciones de Plausible atacadas?

Al menos otra instalación vulnerable de Plausible CE, con la versión 3.2.0, fue comprometida esa misma semana, aunque no hay relación demostrada con Convertr. El 23 de octubre, un administrador abrió una incidencia en el repositorio de Plausible CE. En su contenedor, un script lanzado por beam.smp, la máquina virtual de Erlang sobre la que corre Plausible, había arrancado un minero de criptomonedas disfrazado de proceso del sistema que ocupaba unos tres núcleos de forma continua. El administrador no identificó la vía de entrada, otro usuario enlazó el aviso de seguridad de Plausible y la incidencia se cerró ese mismo día. Era un caso de minería encubierta de criptomonedas (cryptojacking).

¿Quién está detrás del ataque?

Sansec atribuye el ataque a un grupo Magecart brasileño al que sigue desde julio de 2024 y que hasta ahora comprometía comercios de uno en uno. Le atribuye skimmers en decenas de tiendas Magento, OpenCart y WooCommerce, casi todas brasileñas, y en algunas el código estuvo activo cerca de dos años. Convertr es el primer ataque a la cadena de suministro que le atribuye, y el mismo punto de envío, 1x0.is/ws, había aparecido un día antes en el skimmer de otra tienda brasileña.

Entre los rasgos del grupo, la firma describe dominios cortos .is que rota cada pocos meses, webhooks (avisos automáticos) de Discord para recibir los datos y una variante que sustituye el código QR de PIX, el sistema brasileño de pagos instantáneos, por el del atacante.

¿Por qué los controles habituales no lo vieron?

Los controles habituales no lo vieron porque el script llegaba de un origen de confianza y el robo ocurría en el navegador del comprador. Para el comercio, el script venía de un dominio de su plataforma, figuraba entre los orígenes autorizados de su política de seguridad de contenidos (CSP), si la tenía, y llevaba tiempo cargándose sin problemas. Un servidor de analítica tiende a clasificarse como herramienta de marketing, y su ciclo de parches depende de quien lo instaló. Un cortafuegos de aplicaciones web filtra las peticiones que llegan al servidor, mientras que aquí los datos salían desde el navegador hacia un tercer dominio, fuera de su alcance.

La vulnerabilidad, además, vivía en una dependencia de desarrollo. Una zona de pruebas de componentes no tiene función en un servidor de producción, pero viajaba dentro de la imagen oficial y respondía a quien alcanzara el servidor. En organizaciones con años de integraciones acumuladas es frecuente que estas piezas sigan en la versión del día de la instalación. Un inventario de software (SBOM) la habría hecho visible como dependencia, y un análisis de la superficie de ataque externa podría haber detectado que /storybook respondía.

¿Cómo se detecta un skimmer escondido en un script de la casa?

Un skimmer así se detecta vigilando el servidor que aloja el script, el contenido que recibe el comprador y las conexiones que abre el navegador.

¿En qué hay que fijarse en el servidor que aloja el script?

En el servidor hay que revisar los registros de acceso, los procesos y la integridad de los ficheros servidos. Si aparecen peticiones a /storybook, Sansec recomienda reconstruir el servidor, rotar los secretos y comparar los ficheros de priv/tracker/js/ con los de la versión oficial.

Un intérprete de comandos, wget o curl lanzados por beam.smp difícilmente tienen explicación legítima en Plausible. En la incidencia del 23 de octubre, el minero se remontaba a un proceso hijo inesperado de beam.smp, y un EDR (detección y respuesta en el endpoint) o auditd bien configurados pueden registrarlo. Para los ficheros sirve un hash (huella criptográfica) de referencia del script de seguimiento, con una alerta si cambia fuera de una actualización planificada.

¿Cómo se comprueba lo que recibe el comprador?

Lo que recibe el comprador se comprueba desde fuera, descargando cada cierto tiempo los scripts de la página de pago, calculando su hash y comparándolo con el aprobado. Cubre la parte de scripts del requisito 11.6.1 de PCI DSS, que también pide vigilar las cabeceras HTTP. Sansec publicó además el SHA-256 de la copia infectada del 26 de octubre, útil para búsquedas retrospectivas en registros de proxy o en cachés.

¿Puede el navegador bloquear el robo?

El navegador puede bloquear el envío de los datos con una CSP y la ejecución del fichero alterado con la integridad de subrecursos. Una CSP con la directiva connect-src limitada a los dominios de la pasarela y del comercio habría bloqueado el envío a 1x0.is. Esa directiva rige las conexiones de fetch, XHR y WebSocket, incluidas las peticiones en modo no-cors como la que usaba el skimmer.

En modo de solo informe (Content-Security-Policy-Report-Only) la política no bloquea, pero avisa del primer intento de conexión a un dominio no autorizado. Report URI, un servicio que recoge esos informes, sostiene que este modo es suficiente para la autorización que pide el 6.4.3 y para alimentar la detección de cambios del 11.6.1, aunque bloquear protege más.

La integridad de subrecursos (SRI), un atributo integrity con el hash del script en la etiqueta que lo carga, habría impedido que el navegador ejecutara el fichero alterado. Su coste es operativo, porque cada actualización legítima obliga a cambiar el hash. Por eso encaja mejor con scripts autoalojados y versionados, como un Plausible instalado en casa.

¿Qué exige PCI DSS sobre los scripts de la página de pago?

PCI DSS v4 exige desde el 31 de marzo de 2025 dos requisitos pensados para este tipo de ataque, según el PCI Security Standards Council. El 6.4.3 pide que cada script de la página de pago esté autorizado, tenga su integridad asegurada y figure en un inventario con una justificación escrita. El 11.6.1 pide un mecanismo que detecte cambios no autorizados en esos scripts y en las cabeceras HTTP que afectan a la seguridad de la página, tal como los recibe el navegador, y que alerte de ellos.

¿Quedan exentos los comercios que presentan el SAQ A?

Los comercios que presentan el SAQ A no están exentos, aunque esos dos requisitos hayan desaparecido de su cuestionario. El PCI SSC los retiró del SAQ A, el cuestionario de los comercios que externalizan por completo la captura de la tarjeta, en la revisión publicada en enero de 2025 y vigente desde el 31 de marzo. En su lugar introdujo un criterio de elegibilidad según el cual el comercio debe confirmar que su web no es susceptible a ataques de scripts que puedan afectar a sus sistemas de comercio electrónico.

La FAQ 1588, de febrero de 2025, permite demostrarlo con técnicas como las del 6.4.3 y el 11.6.1 o con la confirmación de un proveedor de servicios que cumpla PCI DSS. Según Report URI, el proveedor de pagos no suele ver la página del comercio que aloja su formulario, y pocos aceptan firmar que está protegida. La mayoría de los comercios acaba necesitando, por tanto, controles equivalentes.

¿Cuál es el papel de la plataforma que aloja la página de pago?

En un modelo como el de Convertr, la plataforma tiene el control técnico del script, y la evidencia que cada comercio pueda aportar depende de lo que ella vigile. Por eso el comercio debe preguntarle qué scripts cargan las páginas de pago que sirve, quién los autoriza y cómo se le avisará si cambian. Esa pregunta forma parte de la gestión del riesgo de terceros.

Si se aplica el RGPD, por ejemplo a un comercio establecido en la UE, el robo de la tarjeta y del nombre del titular es además una violación de datos personales. Según el artículo 33, la plataforma, si actúa como encargada del tratamiento, debe avisar al comercio sin dilación indebida. El comercio, como responsable, debe notificarla a la autoridad de control (la AEPD en España) en un máximo de 72 horas desde que tenga constancia, salvo que sea improbable que suponga un riesgo para las personas afectadas.

¿Con qué medidas se reduce el riesgo de las herramientas auxiliares autoalojadas?

Cuatro medidas reducen el riesgo de los componentes que se instalan una vez y se quedan, como la analítica, los mapas de calor, el chat de soporte, los gestores de etiquetas o las pruebas A/B.

• Cuando su script se carga en la página de pago, la herramienta necesita un dueño y un ciclo de gestión de parches equivalentes a los del sistema de pagos. Entra entonces en el inventario del 6.4.3 y, según la arquitectura, en el alcance de PCI DSS.
• El servidor de analítica solo tiene que entregar el script y recibir eventos, así que el panel de administración y las rutas de desarrollo pueden quedar detrás de una lista de direcciones permitidas o de un acceso autenticado.
• Los campos de tarjeta alojados por la pasarela dentro de un iframe reducen lo que puede leer un script de la página principal, aunque no impiden otros abusos, como sustituir el formulario o el QR de pago.
• Los avisos de seguridad de cada proyecto de código abierto autoalojado tienen que llegar a alguien con capacidad de actuar. Un programa de gestión de vulnerabilidades que incluya estas piezas, junto con un mapa actualizado de la superficie de ataque expuesta, cierra buena parte de ese hueco.

Para quien procesa pagos con tarjeta, el caso sirve para comprobar si dispone de la evidencia que pide un proceso de cumplimiento PCI DSS. Eso empieza por listar los scripts de la página de pago con su justificación y anotar, para cada uno, qué servidor lo entrega y en qué versión está. Una auditoría de seguridad de aplicaciones web que incluya el lado del cliente alcanza lo que las pruebas del servidor no ven.

¿Qué indicadores de compromiso ha publicado Sansec?

Sansec ha publicado el destino de exfiltración, el fichero infectado con su hash y los dominios que el grupo usó antes. Sirven para revisar registros de proxy, DNS y cortafuegos en busca de estos indicadores de compromiso.

• Destino de exfiltración: 1x0.is, en la ruta /ws.
• Fichero infectado: analytics.convertr.app.br/js/script.pageview-props.tagged-events.js, con SHA-256 ee4618d24737eff785e5a267b55903d5ef6ff7ecbeb099347a67fee77734d7f7 (copia del 26 de octubre).
• Dominios de exfiltración anteriores del mismo grupo: snf.is, kk.land, nmn.is, kof.one, anl.is, xsox.diy, eqp.is, shy.is, blz.is, tray.is, miorl.net, xwv.is, fasthook.app y antiddos-protection.net.

Como el grupo rota sus dominios cada pocos meses, estos indicadores sirven sobre todo para mirar atrás. Para la vigilancia continua resulta más útil una regla de comportamiento que alerte de toda petición saliente desde una página de pago hacia un dominio fuera de la lista aprobada.

¿Dónde falla el inventario de scripts de pago?

El inventario que pide PCI DSS suele fallar en una columna, la del servidor que entrega cada script, su versión y quién responde de ella. Mientras el servidor de analítica figure en la columna de marketing, su versión, sus rutas expuestas y sus avisos de seguridad no suelen pasar por el mismo filtro que la pasarela, aunque su código se ejecute junto al número de tarjeta.

El mismo patrón aparecía en las cinco lecciones de la cadena de suministro digital para el CISO y en el caso de las webs WordPress actualizadas que recibieron un implante oculto.

Fuentes y atribución: este análisis se basa en divulgaciones públicas disponibles a 30 de octubre de 2026, principalmente la investigación de Sansec, la declaración de Convertr a Canaltech, los avisos de seguridad de Plausible y GitHub y la documentación del PCI SSC. Que la entrada se produjera por CVE-2026-8467 es una hipótesis de Sansec sin confirmar. La mención de Plausible no implica que sus versiones actuales estén afectadas por la CVE-2026-8467, corregida en la 3.2.1. La atribución a un grupo Magecart brasileño procede de Sansec y puede evolucionar.

Las configuraciones descritas (CSP, SRI, control de integridad y reglas de detección) son orientativas y deben probarse antes en preproducción, porque una política demasiado estricta puede romper la página de pago. Las referencias a PCI DSS y al RGPD no sustituyen la valoración de un evaluador cualificado (QSA) ni el asesoramiento jurídico para cada entorno.