Script de Plerdy comprometido: qué revisar en tu web

La firma de ciberseguridad Sekoia publicó el 4 de noviembre de 2026 que el script de Plerdy, un servicio de analítica web y SEO, estuvo alterado entre el 27 de agosto y el 3 de septiembre. Las webs que lo cargaban sirvieron a sus visitas ataques contra móviles sin actualizar. Afecta a quien tenga Plerdy instalado.

Lo que se sabe

El archivo: según Sekoia, los atacantes inyectaron código en el archivo legítimo `main.js` del rastreador de Plerdy, servido desde a.plerdy.com. Sekoia dice que ese script lo cargan «miles de webs», en su gran mayoría ucranianas, y lo llama también «Plerdy SEO Tracker».
Las fechas: Sekoia sitúa la manipulación entre el 27 de agosto y el 3 de septiembre de 2026, una semana. Su equipo descubrió la campaña a mediados de octubre y publicó el informe el 4 de noviembre.
Qué hacía: el código cargaba un script de huella digital desde otro dominio y, según el tipo de móvil, servía una de tres cadenas de ataque: iPhone con iOS 16.7 (robo de cookies), iPhone con iOS 18.5 (robo de datos del aparato) y Android con Chrome de la versión 139 a la 145, salvo la 143 (robo de datos de Chrome y de contraseñas wifi).
Quién, según Sekoia: atribuye la campaña a APT29, el grupo vinculado por varios gobiernos a la inteligencia rusa, «o al menos uno de sus subgrupos», con confianza moderada a alta. Es una evaluación de Sekoia, no una conclusión judicial.
Más allá de Plerdy: el mismo informe describe otras webs alteradas directamente (en una, los atacantes modificaron una biblioteca JavaScript que ya usaba el sitio) y webs falsas que copiaban a otras en tiempo real.
Los fallos ya tienen parche: Sekoia dice que todas las cadenas usan vulnerabilidades ya corregidas y que un móvil con el sistema al día está a salvo.

Qué cambia y qué no

Las víctimas eran las visitas, no el servidor. El código corría en el navegador de quien abría la web. El informe no habla de robo de datos de las webs que cargaban el script.
Hay cosas que el informe no dice: cómo se alteró el archivo, si Plerdy fue avisada ni si lo corrigió (solo que la manipulación duró una semana). El 4 de noviembre no aparecía un comunicado de Plerdy sobre el caso.
Es el segundo caso en una semana. A finales de octubre, el script de medición de DebugBear sirvió código malicioso tras el secuestro de su DNS. Un script de terceros corre en tu web con los mismos permisos que tu propio código.

Cómo saber si te afecta

Busca «plerdy» en tu web: en el código fuente de la página, en la pestaña Red de las herramientas del navegador y en tu gestor de etiquetas (Google Tag Manager u otro). Revisa también plugins y módulos de analítica.
Si lo cargabas entre el 27 de agosto y el 3 de septiembre, tus visitas con móviles sin actualizar pudieron recibir el ataque. Si tu web tiene inicio de sesión, cierra las sesiones abiertas y comprueba que las cookies de sesión llevan el atributo HttpOnly, que impide leerlas desde JavaScript.
Decide si lo mantienes y pide a Plerdy por escrito qué pasó y qué cambió. Mientras no haya respuesta, sácalo al menos de las páginas de inicio de sesión, pago o área de clientes.
Haz la lista de scripts externos y quita los de servicios que ya no usas. Report URI documentó en octubre más de 660 dominios de servicios abandonados que alguien volvió a registrar para servir código a las webs que seguían cargándolos.
Limita a dónde puede ir tu código: una política de seguridad de contenido (CSP) que solo permita los dominios de la lista, y avisos cuando aparezca un script nuevo. No para un archivo legítimo alterado, pero reduce el daño.
Actualiza tu propio móvil y pide lo mismo a tu equipo: es la defensa que el informe da por suficiente.

Relacionado: Script de DebugBear comprometido: qué hacer en tu web

Fuentes

Actualizaciones: si Plerdy publica un comunicado o Sekoia amplía los datos de las webs afectadas, se añadirá aquí con su enlace.