Ataque cadena suministro OptinMonster afecta 1.2M

El 13 de junio de 2026, Sansec descubrió un ataque de cadena de suministro activo que golpeó a más de 1.2 millones de sitios WordPress a través de OptinMonster, TrustPulse y PushEngage, tres plugins operados por Awesome Motive. El código malicioso no estaba alojado en los servidores de las víctimas, sino que se inyectó directamente en los archivos JavaScript servidos desde el CDN oficial de la empresa. Cada sitio que cargaba esos scripts recibía la versión adulterada sin advertencia alguna y sin forma de detectarlo desde el panel de administración.

Un ataque de cadena de suministro en WordPress ocurre cuando un actor compromete un eslabón upstream —en este caso, el CDN de Awesome Motive— y el código malicioso se distribuye automáticamente a todos los sitios que dependen de ese recurso. No necesitás haber instalado nada raro ni tener un plugin vulnerable en tu servidor: el simple hecho de tener OptinMonster activo y cargar su script desde la CDN oficial era suficiente para quedar expuesto. Es el mismo patrón que Sansec ya había documentado en el ataque a Polyfill en 2024: adulterás un solo archivo upstream y la infección se propaga a miles de sitios sin tocarlos individualmente.

¿Qué es exactamente un ataque de cadena de suministro como el de OptinMonster?

Un ataque de cadena de suministro en el ecosistema WordPress se da cuando un actor malicioso compromete un componente que los sitios consumen de forma automática —una librería, un script de CDN, una dependencia de composer— y la infección se propaga aguas abajo sin que los administradores muevan un dedo. La diferencia con un ataque tradicional a un plugin es brutal: no hace falta que el atacante encuentre una vulnerabilidad en tu sitio, ni que vos instales una versión pirateada de nada, ni que un colaborador cometa un error de configuración. Alcanza con que el proveedor que vos elegiste —y en quien confiaste— tenga un agujero en su infraestructura.

En este caso, el código malicioso se alojaba en los endpoints del CDN de Awesome Motive, la empresa detrás de OptinMonster, TrustPulse y PushEngage. Cada sitio que usaba alguno de estos plugins cargaba el JavaScript adulterado directamente desde la fuente oficial, sin que hubiera forma de notarlo desde el panel de WordPress. Fijate la ironía: el archivo era servido por el mismo dominio de siempre, con el mismo certificado SSL de siempre, desde la misma infraestructura que siempre (sí, todo parecía normal).

Sansec —el equipo forense que detectó el ataque el 13 de junio de 2026— lo comparó explícitamente con el caso Polyfill de 2024: adulterás un solo archivo en un punto de distribución central y la infección llega a millones de sitios sin tocarlos individualmente. La campaña seguía activa al momento de la publicación del reporte. Te puede servir nuestra cobertura en nuestra guía completa sobre CVE.

¿Qué plugins de Awesome Motive se vieron afectados?

Tres plugins confirmados con código malicioso en sus scripts de CDN:

• OptinMonster: más de 1 millón de instalaciones activas en WordPress. Es el más golpeado por una cuestión de escala.
• TrustPulse: plugin de notificaciones de prueba social, también con distribución masiva.
• PushEngage: notificaciones push para navegadores, bastante popular en sitios de ecommerce y marketing.

Ahora bien, Awesome Motive maneja un portafolio enorme. WPForms (6 millones de instalaciones), MonsterInsights (2 millones), All in One SEO (3 millones) y otros productos no tenían código comprometido en sus scripts al momento del reporte de Sansec. Ojo con esto: el hecho de que no se haya encontrado código malicioso en esos otros plugins no significa que el atacante no haya tenido acceso a sus pipelines. Es una distinción importante.

¿Cómo funcionaba el malware? Paso a paso técnico

El flujo del ataque está minuciosamente documentado en el análisis forense de Sansec y vale la pena recorrerlo porque es un caso de manual sobre cómo opera un ataque de cadena de suministro moderno:

• 1. Carga del JavaScript malicioso: el script adulterado se descargaba desde el CDN de Awesome Motive cuando un visitante —cualquier visitante— cargaba una página del sitio WordPress que tuviera el plugin activo. Pero el payload no se ejecutaba para cualquiera.
• 2. Detección de administrador logueado: el código verificaba si el visitante era un usuario administrador con sesión activa en WordPress. Si eras un visitante común, no pasaba nada. Si estabas logueado como admin, activaba la maquinaria.
• 3. Recolección de tokens y nonces: el script extraía los tokens de autenticación disponibles en el DOM y los usaba para operar como si fuera el administrador legítimo.
• 4. Creación de cuenta admin: acá viene lo interesante. El malware intentaba cuatro métodos distintos para crear una cuenta de administrador, en cascada: vía user-new.php, vía admin-ajax.php, vía la API REST en wp/v2/users y —si todo lo demás fallaba— mediante un iframe oculto. Cuatro caminos distintos. Si uno no funcionaba, pasaba al siguiente.
• 5. Instalación del plugin backdoor: una vez creada la cuenta, el script instalaba un plugin oculto disfrazado como «Content Delivery Helper» v2.7.1 o «Database Optimizer» v2.9.4. Este plugin no aparece en el listado del dashboard, no responde a la REST API, se oculta de los checks de actualización y desaparece del registro de plugins activos recientemente.
• 6. Exfiltración de credenciales: las nuevas credenciales se enviaban a tidio.cc —un dominio que imita al legítimo tidio.com— usando una clave XOR (jX9kM2nP4qR6sT8v) y cuatro métodos de envío en fallback: sendBeacon, fetch, XMLHttpRequest y un objeto Image. Si uno fallaba, el siguiente tomaba la posta.

Subís el script, esperás a que un admin se loguee, el malware crea una cuenta nueva con privilegios completos, instala un backdoor que no se ve desde ningún lado, y manda las llaves del reino a un servidor externo usando un dominio preparado para pasar desapercibido. Así de quirúrgico fue.

¿Qué cuentas de administrador y plugins backdoor crea el ataque?

Según el reporte de Sansec, el malware crea dos tipos de cuentas administrativas: Lo explicamos a fondo en proteger tu sitio con un WAF.

• developer_api1: asociada al correo customer1usx@gmail.com. Es una cuenta fija que el atacante puede reutilizar en múltiples sitios.
• Cuentas aleatorias: con el formato dev_ seguido de nueve caracteres alfanuméricos (por ejemplo, dev_aB3xZ9kL2).

El plugin backdoor se instala con nombres que parecen herramientas legítimas de mantenimiento. «Content Delivery Helper» versión 2.7.1 o «Database Optimizer» versión 2.9.4 suenan a algo que un desarrollador podría haber instalado para mejorar la performance del sitio. El truco es que el plugin se oculta del listado de plugins en el dashboard, no aparece en la REST API de WordPress, se excluye de los checks de actualización y desaparece del registro de plugins activos recientemente. Si solo mirás el panel de administración, no lo ves.

¿Cómo detectar si mi sitio WordPress fue comprometido?

Primero lo primero: no confíes en el dashboard de WordPress para esta verificación. El malware está diseñado para ser invisible desde el panel. Lo que tenés que hacer es ir directo a la base de datos y al sistema de archivos.

• Revisá la tabla wp_users: buscá usuarios con nombres como developer_api1 o que empiecen con dev_ seguido de caracteres aleatorios. Si tenés acceso a phpMyAdmin o a la consola MySQL, ejecutá SELECT * FROM wp_users WHERE user_login LIKE 'dev_%' OR user_login = 'developer_api1';. Ojo con el prefijo wp_, cambiá el nombre de la tabla si tu instalación usa otro prefijo.
• Buscá los directorios de los plugins backdoor: en wp-content/plugins, buscá las carpetas content-delivery-helper o database-optimizer. Si existen, estás comprometido.
• Escaneo server-side: un escáner que solo revise el dashboard de WordPress no va a encontrar nada. Necesitás una herramienta que mire el sistema de archivos y la base de datos directamente. Si tu hosting incluye escaneo de malware a nivel servidor —en donweb.com los planes de hosting WordPress incluyen esta capa—, ejecutalo de inmediato.

¿Qué medidas de seguridad urgentes debo tomar?

Si encontrás cualquiera de los indicadores que mencioné arriba, tenés que asumir que el atacante tuvo ejecución de código no autenticada en tu sitio. Eso significa que potencialmente pudo hacer cualquier cosa: modificar archivos, leer la base de datos, inyectar redirecciones, instalar puertas traseras adicionales.

Esto es lo que tenés que hacer, en este orden y sin saltearte nada:

• Rotá TODAS las contraseñas de administrador: todas. No solo las que veas sospechosas.
• Rotá las claves API y credenciales de servicios externos: si tu sitio se conecta a pasarelas de pago, servicios de email marketing, APIs de redes sociales o cualquier integración, generá nuevas claves y revocá las anteriores.
• Cambiá las credenciales de la base de datos y los salts de wp-config.php: el atacante pudo leer wp-config.php. Nuevos salts, nueva contraseña de BD, nueva clave de autenticación.
• Hacé un escaneo server-side completo: no un escaneo desde el dashboard. Algo que mire el sistema de archivos, los procesos en ejecución, las conexiones salientes, los cron jobs.
• Eliminá los plugins backdoor y las cuentas admin fraudulentas: desde la base de datos y el sistema de archivos, no desde el panel.

¿Cómo ocurrió la brecha en el CDN de Awesome Motive?

OptinMonster publicó un comunicado oficial tras el incidente. Los reportes de Sansec indican que la campaña seguía activa el 13 de junio, y usuarios de OptinMonster venían reportando interrupciones del servicio en paralelo. El timeframe exacto de la ventana de exposición no ha sido detallado públicamente. ¿Alguien externo auditó la remediación completa? Hasta donde pude verificar, no.

Qué está confirmado y qué no

Errores comunes al responder a este ataque

Confiar en el escaneo del dashboard de WordPress. Es el error más grave que veo en incidentes como este. El plugin backdoor está diseñado para ocultarse del panel de administración, de la REST API y de los checks de actualización. Si tu verificación de seguridad termina en el dashboard, no verificaste nada. Tema relacionado: cómo protegerte contra ataques DDoS.

Eliminar solo las cuentas admin sospechosas y dar el sitio por limpio. El malware instala un plugin backdoor que permite ejecución remota de código. Borrar la cuenta sin eliminar el plugin es como cambiar la cerradura pero dejar la puerta del patio abierta. El atacante puede volver a entrar sin necesidad de credenciales.

No rotar las claves API y credenciales de servicios externos. Si el atacante tuvo acceso de escritura al sistema de archivos y lectura a la base de datos, pudo haber extraído las claves de API de tu pasarela de pago, tu servicio de email o cualquier integración. Rotar las contraseñas de WordPress sin tocar las claves API es un parche a medias.

Pensar que con desactivar OptinMonster alcanza. El código malicioso ya se ejecutó. Si tuviste el plugin activo durante la ventana de exposición y un administrador se logueó, el daño potencial ya está hecho. Desactivar el plugin ahora no revierte la creación de cuentas ni la instalación del backdoor. Son dos problemas distintos: mitigar la fuente del ataque (desactivar o actualizar) y remediar la infección (limpiar lo que ya entró).

Preguntas Frecuentes

¿OptinMonster tuvo un ataque de suministro?

Sí. El 13 de junio de 2026, Sansec descubrió que el CDN de Awesome Motive —la empresa dueña de OptinMonster— estaba sirviendo JavaScript malicioso a más de 1.2 millones de sitios WordPress que usan OptinMonster, TrustPulse y PushEngage. El ataque estuvo activo durante varios días y permitía a los atacantes crear cuentas de administrador ocultas e instalar plugins backdoor. En la seguridad que ofrece WPForms profundizamos sobre esto.

¿Cómo eliminar el backdoor database-optimizer de WordPress?

El plugin malicioso se aloja en wp-content/plugins/database-optimizer (o content-delivery-helper). No lo vas a ver en el dashboard. Tenés que eliminarlo directamente desde el sistema de archivos, borrando la carpeta completa. Después revisá la tabla wp_users para eliminar las cuentas admin fraudulentas, rotá todas las contraseñas, cambiá las claves API y los salts de wp-config.php, y ejecutá un escaneo server-side para verificar que no haya quedado nada.

¿TrustPulse y PushEngage también fueron hackeados?

Sí, ambos plugins distribuyeron el mismo JavaScript malicioso desde el CDN de Awesome Motive. El vector de ataque fue idéntico en los tres casos: archivos adulterados en los endpoints del CDN oficial. Si tenés cualquiera de los tres plugins activo, aplican las mismas medidas de detección y remediación.

¿Qué hacer si mi sitio WordPress está infectado?

Asumí que el atacante tuvo ejecución de código completa. Revisá la base de datos en busca de cuentas admin no reconocidas, buscá los directorios de plugins backdoor en el sistema de archivos, rotá todas las contraseñas y claves API, cambiá las credenciales de la base de datos y los salts de wp-config.php. Ejecutá un escaneo de malware a nivel servidor —no un escaneo desde el dashboard de WordPress— y monitorizá las conexiones salientes de tu servidor durante los días siguientes.

¿Qué usuarios admin ocultos crea el malware?

El malware crea dos tipos de cuentas administrativas: una fija llamada developer_api1 con el correo customer1usx@gmail.com, y múltiples cuentas con el formato dev_ seguido de nueve caracteres alfanuméricos aleatorios. Revisá la tabla wp_users directamente en la base de datos porque estas cuentas pueden no aparecer en el listado del dashboard.

Conclusión

Este ataque deja una enseñanza dura sobre la dependencia de infraestructura de terceros en WordPress. OptinMonster es un plugin masivo, mantenido por una de las empresas más grandes del ecosistema, con años de trayectoria y millones de instalaciones. Y aún así, un atacante encontró la forma de meter código malicioso en su CDN.

Lo que cambió después de este incidente es la conciencia sobre un riesgo que siempre existió pero que pocos tomaban en serio: cuando cargás scripts desde el CDN de un tercero, le estás dando a ese tercero —y a cualquiera que comprometa su infraestructura— la capacidad de ejecutar código arbitrario en tu sitio. No hay forma técnica de evitarlo sin auditar cada script que cargás, y seamos honestos, nadie audita el JavaScript de OptinMonster cada vez que se actualiza.

Si tenés sitios WordPress en producción, hoy es un buen día para revisar qué plugins cargan recursos desde CDNs externos, documentar esas dependencias y asegurarte de que tu plan de respuesta a incidentes contempla un escenario donde el proveedor de confianza es el vector de ataque. Porque si algo demostró este caso es que puede pasar, y cuando pasa, la escala es devastadora.

Fuentes

• Sansec Forensics Team – OptinMonster supply chain attack hits 1.2 million sites — Reporte forense original con el análisis técnico completo del malware, publicado el 13 de junio de 2026.
• Security Affairs – Supply Chain Attack Hits Popular WordPress Plugins Through Awesome Motive CDN — Cobertura ampliada con contexto sobre el portafolio de Awesome Motive, publicada el 15 de junio de 2026.
• OptinMonster – Security Incident: Tampered Script Served via OptinMonster and TrustPulse — Comunicado oficial de Awesome Motive detallando el vector de acceso inicial y las medidas de remediación aplicadas.