Instala un plugin que no aparece en el Panel de Control

Un atacante manipuló archivos JavaScript de confianza utilizados por sitios de WordPress que ejecutan PushEngage, OptinMonster y TrustPulse, convirtiendo esos archivos en una vía para infiltrarse en los sitios.

Cuando un administrador del sitio estaba conectado mientras se cargaba el archivo, el código creaba una cuenta de administrador bajo el control del atacante e instalaba un plugin oculto que permitía el acceso no autorizado. Los visitantes comunes no activaron este mecanismo.

Cualquier sitio web afectado debe considerarse comprometido. Los tres plugins son gestionados por la misma empresa, Awesome Motive, que hasta el 15 de junio no había hecho comentarios sobre los dos plugins más grandes.

La empresa de seguridad Sansec reveló el 13 de junio la existencia de una campaña más amplia, al descubrir que el mismo código malicioso en JavaScript se utilizaba para los tres plugins.

Un día después, PushEngage publicó su propio aviso de incidente, confirmando que un atacante había distribuido copias manipuladas de su script y que los sitios que las cargaban podían ser comprometidos.

PushEngage, adquirida por Awesome Motive hace años, es hasta ahora la única de los tres que ha emitido directrices; los usuarios de OptinMonster y TrustPulse no han recibido ninguna información oficial.

El período de exposición no fue el mismo para cada plugin. Sansec detectó el 12 de junio el código malicioso en OptinMonster y TrustPulse durante solo unos 25 minutos, comenzando alrededor de las 22:17 UTC y desapareciendo a las 22:42. La exposición de PushEngage duró más tiempo: varias horas el 12 de junio, y su script aún se distribuía desde algunos de los servidores de la CDN hasta el 14 de junio.

Así pues, los dos plugins con más sitios web tenían la ventana más pequeña, y PushEngage tenía la más grande.

Sansec estima que los tres plugins alcanzan en conjunto más de 1,2 millones de sitios web, la mayor parte de ellos OptinMonster, que por sí solo cuenta con más de un millón de instalaciones activas. El plugin de PushEngage para WordPress tiene más de 9.000. Esta cifra se refiere al alcance, no al daño: contabiliza los sitios que utilizan los plugins, no los que han sufrido ataques.

Cómo funcionó el ataque

El script malicioso no hacía nada en una página normal. Solo actuaba cuando lo cargaba un administrador de WordPress con sesión iniciada, y entonces utilizaba la sesión de ese administrador para tomar el control.

Ese diseño también explica por qué el panel de control de WordPress no puede indicar si has sido víctima de un ataque: la puerta trasera está diseñada para permanecer fuera de las pantallas de administración, por lo que la única comprobación fiable se realiza en el propio servidor.

En el caso de PushEngage, los archivos manipulados fueron sus archivos incrustados habituales, pushengage-web-sdk.js y pushengage-subscription.js, servidos desde clientcdn.pushengage.com, la red de distribución de contenido que envía el script de PushEngage a los sitios web de los clientes. OptinMonster y TrustPulse fueron atacados a través de puntos de acceso separados de Awesome Motive CDN.

PushEngage afirma que el resto de sus sistemas permanecieron intactos: no encontró indicios de que su aplicación principal o los servidores que almacenan los datos de los clientes hubieran sido accedidos.

Según la propia versión de PushEngage, una vez que el script se ejecutaba con un administrador conectado, ocurría lo siguiente:

1. Utilizó la sesión de ese administrador para actuar con permisos completos,
2. Creó una nueva cuenta de administrador bajo el control del atacante,
3. Instaló un plugin que no aparece en el panel de control y
4. Envía los nuevos datos de inicio de sesión y la información del sitio a tidio[.]cc, un dominio falso diseñado para parecerse al verdadero tidio.com.

Sansec encontró la misma secuencia en los tres plugins. El dominio tidio[.]cc se registró el 28 de abril, semanas antes del ataque, lo que apunta a una operación planificada en lugar de un robo rápido.

El plugin oculto es el verdadero tesoro. Abre lo que se conoce como una shell web, un canal de comandos remoto: cualquiera que conozca la URL correcta puede ejecutar código en el servidor sin iniciar sesión. Desde allí, el atacante puede leer o modificar cualquier archivo, copiar la base de datos, instalar más puertas traseras, inyectar código para clonar tarjetas, redirigir a los visitantes o robar datos.

La cuenta de administrador adicional es una forma sencilla de recuperar el acceso si eliminas el plugin pero no la cuenta. Y dado que el atacante puede ejecutar código libremente, eliminar el plugin y la cuenta mencionados podría no ser suficiente; tanto Sansec como PushEngage recomiendan asumir que podrían quedar otras puertas traseras.

Cómo entró el atacante

Este es el punto en el que discrepan ambas versiones. PushEngage afirma que el atacante primero accedió al servidor que aloja su sitio web de marketing, aprovechando una vulnerabilidad conocida en UpdraftPlus, un plugin de copia de seguridad para WordPress. Dicho servidor es independiente de los sistemas que ejecutan el producto y almacenan los datos de los clientes.

Lo importante no era el servidor en sí, sino una clave que residía en él: una clave API de CDN. Con esa clave, el atacante no necesitaba infiltrarse en los sistemas principales de PushEngage. Simplemente podía modificar los archivos que la CDN ya estaba distribuyendo a los sitios web de los clientes.

Sansec no está convencida de que se haya identificado el punto de entrada. Afirma que aún se desconoce el sistema comprometido, siendo los servidores de Awesome Motive el lugar más probable, la cuenta de CDN una posibilidad y el proveedor de CDN, BunnyNet, una opción improbable.

El análisis público de Sansec no examina ni respalda la teoría de UpdraftPlus; esa información proviene únicamente de PushEngage, sobre su propio entorno. UpdraftPlus sí tiene una vulnerabilidad de omisión de autenticación, CVE-2026-10795, que Wordfence califica con un 8.1 (gravedad alta); ya está parcheada y Wordfence ha reportado ataques en su contra, por lo que cualquier persona que utilice UpdraftPlus debería actualizarla sí o sí.

No se ha confirmado si ese fallo tuvo algo que ver con esta intrusión. Considera el punto de entrada como inestable.

Qué comprobar y qué hacer

Según el cronograma de Sansec, los archivos de OptinMonster y TrustPulse estaban limpios para el 13 de junio, mientras que el script de PushEngage permaneció en algunos servidores CDN hasta el 14 de junio. PushEngage afirma que aún está investigando el período exacto y que, desde entonces, ha reemplazado los archivos defectuosos, borrado la caché de la CDN, cambiado la clave de la CDN y todas las credenciales relacionadas, y trasladado el sitio de marketing a una nueva infraestructura.

Nada de eso limpia un sitio que ya estaba hackeado.

Dado que la puerta trasera se oculta del panel de control, no se puede descartar una posible intrusión simplemente revisando WordPress. Si tu sitio web utilizaba alguno de los tres plugins durante el período en que se detectó la amenaza, la única solución fiable es un análisis del servidor.

No intentes resolverlo adivinando si estabas conectado; la mayoría de los propietarios no pueden demostrarlo. Sigue los pasos que se indican a continuación como punto de partida.

1. Ejecuta un análisis del servidor. Cualquier persona que haya tenido activos PushEngage, OptinMonster o TrustPulse durante el período analizado debe realizar un análisis directo del servidor. Un análisis desde el navegador o el panel de control no detectará la carga útil que solo se ejecutó para los administradores registrados. (Sansec detectó la misma carga útil en los tres plugins, pero no ha confirmado que OptinMonster y TrustPulse se hayan distribuido de la misma manera ni durante el mismo período que PushEngage).

2. Comprueba el sistema de archivos, no el panel de control. En wp-content/plugins, busca las carpetas content-delivery-helper ("Content Delivery Helper") o database-optimizer ("Database Optimizer"). Confía en lo que encuentres en el disco. Elimina cualquier cuenta de administrador que no hayas creado, especialmente developer_api1 o cualquier cuenta que coincida con dev_xxxxxx.

3. Revisa tus registros. Analiza los registros de acceso del servidor web desde el 12 de junio hasta las 14 UTC para detectar el tráfico saliente hacia tidio.cc, incluidas sus rutas /cdn-cgi/, y hacia el servidor del atacante en 84.201.6.54.

4. Si encuentras algo, prepárate para lo peor. Cambia todo: contraseñas de administrador, claves API, credenciales de la base de datos y claves secretas (sales) en wp-config.php. Con la ejecución de código en el servidor, puede haber mayor persistencia.