1,2 millones de sitios, una clave robada y ningún acceso directo: piratas informáticos infectan un número récord de instalaciones de WordPress sin tocar ninguna directamente.

Los atacantes encontraron una forma de acceder a sitios de WordPress a través de extensiones populares en las que los propietarios confiaban sin cuestionarlas. El ataque afectó al código de OptinMonster, TrustPulse y PushEngage, y la zona de riesgo potencial superó los 1,2 millones de sitios.

La campaña fue revelada por especialistas de Sansec. Según los datos de la compañía, un JavaScript malicioso se añadió a archivos legítimos que la empresa Awesome Motive distribuía a los sitios de sus clientes desde sus propios dominios. Como resultado, a los atacantes no les hacía falta comprometer cada recurso por separado. Bastaba con sustituir un archivo en el proveedor, tras lo cual el código infectado se cargaba automáticamente en todos los clientes que usaban las extensiones afectadas.

El código malicioso no se activaba para los visitantes normales. El script esperaba a que un administrador de WordPress accediera al sitio, luego intentaba crear una nueva cuenta con privilegios de administrador e instalar un módulo malicioso oculto. Los datos recopilados se enviaban al dominio tidio.cc, similar al servicio legítimo tidio.com.

Según Sansec, OptinMonster tiene más de 1 millón de instalaciones activas en WordPress. TrustPulse y PushEngage aumentan la escala total del incidente. La campaña se prolongó al menos desde el 13 de junio de 2026, y los usuarios de OptinMonster reportaron al mismo tiempo interrupciones del servicio.

El código malicioso comprobaba si el sitio se ejecutaba en un entorno automatizado, buscaba señales de inicio de sesión de administrador y no se activaba de nuevo antes de 24 horas. A continuación, el script determinaba la ruta a WordPress, recopilaba tokens administrativos y trataba de crear un administrador por varios métodos, incluyendo el formulario para añadir usuarios, peticiones internas de WordPress y el endpoint wp/v2/users.

Tras el acceso exitoso, en el sitio aparecía la cuenta developer_api1 con la dirección customer1usx@gmail.com o cuentas aleatorias con formato dev_xxxxxx. Luego se instalaba un módulo oculto que se hacía pasar por una extensión legítima. Se ha visto con los nombres Content Delivery Helper y Database Optimizer.

El principal peligro del módulo no era que se disfrazara, sino sus capacidades. Se ocultaba en la lista de extensiones, en las comprobaciones de actualizaciones y en la lista de módulos recientemente activos, pero al mismo tiempo abría una web shell a los atacantes y permitía ejecutar código en el servidor sin autorización adicional.

Patchstack ya registró intentos reales de explotación. Los días 14 y 15 de junio los especialistas bloquearon 271 intentos de crear un administrador malicioso en 13 sitios. La mayoría de las peticiones pasaron por wp/v2/users, lo que coincide con la lógica del ataque descrita por Sansec.

Awesome Motive explicó el incidente como resultado de un acceso mediante una vulnerabilidad conocida en la extensión UpdraftPlus. Según la compañía, el atacante obtuvo acceso al servidor del sitio de marketing, encontró allí la clave de la red de entrega de contenido y la usó para sustituir archivos que se descargaban en los sitios de los clientes. Al detectar la manipulación, la empresa restauró los archivos originales, limpió la caché, cambió las claves y trasladó el sitio de marketing a una nueva infraestructura.

Los propietarios de sitios con OptinMonster, TrustPulse o PushEngage deberían revisar no solo el panel de administración de WordPress, sino también los archivos en el servidor. Están en riesgo los sitios donde el administrador inició sesión mientras los atacantes sustituían archivos. Hay que buscar la cuenta developer_api1, la dirección customer1usx@gmail.com, usuarios con formato dev_xxxxxx, así como las carpetas content-delivery-helper y database-optimizer dentro de wp-content/plugins.

Si el sitio ha sido comprometido, cambiar la contraseña no basta. Ese sitio debe considerarse totalmente violado, ya que el módulo malicioso daba a los atacantes la capacidad de ejecutar código en el servidor. En ese caso los administradores tendrán que eliminar el módulo oculto, cambiar contraseñas y claves secretas, revisar los archivos de WordPress y los registros del servidor, y asegurarse de que los atacantes no hayan dejado puertas traseras adicionales.