Un atacante manipuló archivos JavaScript de los plugins PushEngage, OptinMonster y TrustPulse para tomar el control de sitios de WordPress. Al detectar a un administrador conectado, el código creaba una cuenta de admin maliciosa e instalaba un plugin oculto para ejecutar comandos remotamente. Se recomienda a los usuarios realizar un escaneo directo del servidor y revisar el sistema de archivos para eliminar cuentas y carpetas sospechosas.

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 irrumpir en los sitios.

Cuando un administrador del sitio iniciaba sesión mientras se cargaba el archivo, el código creaba una cuenta de administrador bajo el control del atacante e instalaba un plugin oculto que abría una puerta trasera. Los visitantes comunes no activaban este proceso.

Cualquier sitio que haya sido afectado debe ser tratado como comprometido. Los tres plugins son gestionados por una sola empresa, Awesome Motive, que no había comentado sobre los dos plugins más grandes hasta el 15 de junio.

La firma de seguridad Sansec divulgó la campaña el 13 de junio, encontrando el mismo código malicioso en el JavaScript servido para los tres plugins.

PushEngage siguió un día después con su propio aviso de incidente, confirmando que un atacante había servido copias manipuladas de su script y que los sitios que los cargaran podrían ser tomados bajo control.

PushEngage, adquirida por Awesome Motive hace años, es hasta ahora la única de las tres en emitir guías; los usuarios de OptinMonster y TrustPulse no han recibido nada oficial.

La ventana de exposición no fue la misma para cada plugin. Sansec vio el código malicioso en OptinMonster y TrustPulse solo durante unos 25 minutos el 12 de junio, primero alrededor de las 22:17 UTC y desapareciendo a las 22:42. La exposición de PushEngage fue más larga: varias horas el 12 de junio, y su script siguió sirviéndose desde algunos servidores de la CDN hasta el 14 de junio.

Así que los dos plugins con más sitios tuvieron la ventana más pequeña, y PushEngage tuvo la más grande.

Sansec estima que los tres plugins llegan a más de 1,2 millones de sitios entre todos, la gran mayoría de ellos OptinMonster, que solo tiene más de un millón de instalaciones activas. El plugin de WordPress de PushEngage tiene más de 9.000. Esa cifra es el alcance, no el daño: cuenta los sitios que ejecutan los plugins, no los sitios que fueron vulnerados.

Cómo funcionó el ataque

El script envenenado no hacía nada en una vista de página normal. Actuaba solo cuando un administrador de WordPress conectado lo cargaba, utilizando entonces la sesión de ese administrador para tomar el control.

Este diseño es también la razón por la cual el panel de WordPress no puede decirte si fuiste afectado: la puerta trasera está diseñada para mantenerse fuera de las pantallas de administración, por lo que la única verificación fiable es en el propio servidor.

En el caso de PushEngage, los archivos manipulados eran sus insertos normales, pushengage-web-sdk.js y pushengage-subscription.js, servidos desde clientcdn.pushengage.com, la red de entrega de contenidos (CDN) que distribuye el script de PushEngage a los sitios de los clientes. OptinMonster y TrustPulse fueron afectados a través de endpoints de CDN independientes de Awesome Motive.



PushEngage afirma que el resto de sus sistemas no fueron tocados: no encontró señales de que su aplicación principal o los servidores que contienen los datos de los clientes fueran alcanzados.

Según el propio relato de PushEngage, una vez que el script se ejecutó con un administrador conectado, este:

1. utilizó la sesión de ese administrador para actuar con permisos totales,
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. envió los nuevos detalles de acceso y la información del sitio a tidio[.]cc, un dominio falso creado para parecerse al real tidio.com.

Sansec encontró la misma secuencia en los tres plugins. El dominio tidio[.]cc fue registrado 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 premio. Abre lo que se conoce como una "web shell", un canal de comandos remoto: cualquier persona que conozca la URL correcta puede ejecutar código en el servidor sin iniciar sesión. Desde allí, el atacante puede leer o cambiar cualquier archivo, copiar la base de datos, plantar más puertas traseras, inyectar código para el robo de tarjetas, redirigir visitantes o robar datos.

La cuenta de administrador extra es una forma sencilla de volver a entrar si borras el plugin pero olvidas la cuenta. Y debido a que el atacante puede ejecutar código libremente, eliminar el plugin y la cuenta nombrados puede no ser suficiente; tanto Sansec como PushEngage dicen que debes asumir que podrían quedar otras puertas traseras.

Cómo entró el atacante

Esta es la parte en la que las dos versiones no coinciden. PushEngage dice que el atacante primero entró en el servidor que ejecuta su sitio web de marketing, a través de un fallo conocido en UpdraftPlus, un plugin de copias de seguridad de WordPress. Ese servidor es independiente de los sistemas que ejecutan el producto y almacenan los datos de los clientes.

Lo que importaba no era el servidor en sí, sino una clave almacenada en él: una clave API de la CDN. Con esa clave, el atacante no necesitó irrumpir en los sistemas principales de PushEngage; simplemente pudo cambiar los archivos que la CDN ya estaba entregando a los sitios de los clientes.

Sansec no está convencido de que el punto de entrada esté resuelto. Afirma que el sistema vulnerado sigue siendo desconocido, siendo los servidores de Awesome Motive el lugar más probable, la cuenta de la CDN una posibilidad y el proveedor de la CDN, BunnyNet, improbable.

El análisis público de Sansec no examina ni respalda la teoría de UpdraftPlus; esa versión proviene únicamente de PushEngage sobre su propio entorno. UpdraftPlus tiene un error independiente de omisión de autenticación, CVE-2026-10795, que Wordfence califica como 8.1 (gravedad alta); ya está parcheado, y Wordfence ha informado de ataques contra él, por lo que cualquier persona que use UpdraftPlus debe actualizarse sin importar nada.

Si ese error tuvo algo que ver con esta intrusión no está confirmado. Trata el punto de entrada como no resuelto.

Qué revisar y hacer

Según la cronología de Sansec, los archivos de OptinMonster y TrustPulse estaban limpios para el 13 de junio, mientras que el script de PushEngage persistió en algunos servidores de la CDN hasta el 14 de junio. PushEngage dice que todavía está determinando la ventana exacta y que desde entonces ha reemplazado los archivos maliciosos, limpiado la caché de la CDN, cambiado la clave de la CDN y todas las credenciales relacionadas, y movido el sitio de marketing a una nueva infraestructura.

Nada de eso limpia un sitio que ya ha sido tomado bajo control.


Indicadores de Compromiso (IoCs) de Sansec

Debido a que la puerta trasera se oculta del panel de control, no puedes descartar el compromiso mirando WordPress. Si tu sitio ejecutó cualquiera de los tres plugins durante la ventana de amenaza, la única respuesta fiable es un escaneo del lado del servidor.

No intentes resolverlo adivinando si habías iniciado sesión; la mayoría de los propietarios no pueden probarlo de ninguna manera. Trata los pasos a continuación como la base.

1. Ejecuta un escaneo del lado del servidor. Cualquiera que haya tenido PushEngage, OptinMonster o TrustPulse activos durante la ventana debe escanear el servidor directamente. Una revisión del navegador o del panel omitirá una carga útil que solo se ejecutó para administradores conectados. (Sansec vio la misma carga útil en los tres plugins, pero no ha confirmado que OptinMonster y TrustPulse fueran entregados de la misma manera o en la misma ventana que PushEngage).
2. Revisa el sistema de archivos, no el panel. En wp-content/plugins, busca carpetas llamadas content-delivery-helper ("Content Delivery Helper") o database-optimizer ("Database Optimizer"). Confía en lo que está en el disco. Elimina cualquier cuenta de administrador que no hayas creado, especialmente developer_api1 o cualquier cosa que coincida con dev_xxxxxx.
3. Revisa tus registros. Revisa los registros de acceso del servidor web del 12 al 14 de junio UTC para buscar tráfico saliente hacia tidio.cc, incluyendo sus rutas /cdn-cgi/, y hacia el servidor del atacante en 84.201.6.54.
4. Si encuentras algo, asume lo peor. Rota todo: contraseñas de administrador, claves API, credenciales de la base de datos y las claves secretas (salts) en wp-config.php. Con la ejecución de código en el servidor, es posible que permanezca más persistencia.

Fuente:
THN