30+ plugins WordPress infectados en ataque supply chain

Un actor malicioso compró más de 30 plugins de WordPress en el marketplace Flippa, inyectó un backdoor PHP en todos ellos en agosto de 2025, y lo dejó dormante durante 8 meses antes de activarlo el 5-6 de abril de 2026, comprometiendo más de 20.000 sitios activos con spam SEO invisible dirigido solo a Googlebot, usando smart contracts de Ethereum como infraestructura de comando y control.

¿Qué es un ataque de supply chain en WordPress?

Un ataque de supply chain en WordPress ocurre cuando el código malicioso se introduce en la cadena de distribución del software antes de que llegue al usuario final, ya sea comprometiendo el repositorio oficial, el servidor de actualizaciones, o en este caso, adquiriendo directamente la propiedad de los plugins legítimos.

La diferencia con un ataque directo es importante: acá no se rompió ningún servidor, no se explotó una vulnerabilidad técnica en WordPress.org. Alguien simplemente compró los plugins como si fuera cualquier negocio digital en Flippa, y luego los convirtió en vectores de ataque. El plugin tenía reseñas positivas, historial de actualizaciones, usuarios que confiaban en él. Esa confianza es exactamente lo que se explotó.

WordPress es estructuralmente vulnerable a esto porque no tiene ningún mecanismo para revisar transferencias de propiedad de plugins, no exige firma de código para actualizaciones, y las cuentas de desarrollador no requieren autenticación de dos factores. Cualquiera que compre un plugin puede subir una actualización y llega automáticamente a todos los sitios que tienen activadas las actualizaciones automáticas.

Timeline del ataque Essential Plugin: 8 meses dormante

La cronología es lo que hace a este caso especialmente preocupante.

A principios de 2025, el atacante, identificado por investigadores como alguien con antecedentes en SEO, criptomonedas y marketing de apuestas online, compró el portfolio completo de Essential Plugin en Flippa por una suma de seis cifras en dólares. Flippa estaba tan contenta con la transacción que publicó un caso de estudio sobre la venta en julio de 2025.

Para entonces, el backdoor ya estaba adentro.

El código malicioso se inyectó en agosto de 2025 y durmió sin hacer nada durante 8 meses. Sin llamadas a servidores externos, sin actividad sospechosa, sin alertas. Cualquier scanner de seguridad que hubiese revisado los plugins en ese período probablemente no habría encontrado nada activo. El 5 y 6 de abril de 2026, el atacante activó el payload en forma masiva. WordPress.org respondió el 7 de abril cerrando permanentemente los 31 plugins del autor. Las actualizaciones forzadas llegaron a los sitios afectados, pero el daño ya estaba hecho.

Los 30+ plugins comprometidos: escala e impacto

Según el reporte de The Next Web, WordPress.org cerró 31 plugins del autor Essential Plugin el 7 de abril de 2026. Entre los confirmados está Countdown Timer Ultimate, que fue el primer caso documentado públicamente cuando un cliente reportó la alerta en wp-admin. Widget Logic es otro nombre conocido en la lista (el mismo investigador de Anchor Host había cubierto un ataque anterior sobre ese plugin).

El total de instalaciones comprometidas supera las 400.000, con más de 20.000 sitios activos afectados directamente. La misma semana, por separado, Smart Slider 3 Pro (con más de 800.000 instalaciones) fue comprometido a través de su infraestructura de actualización. Dos ataques distintos, misma semana, misma superficie de ataque estructural.

Cómo funciona el malware: Ethereum smart contracts como C2

Acá viene lo técnicamente interesante, y lo que hace a este ataque diferente de los habituales.

El módulo malicioso se conectaba a analytics.essentialplugin.com, descargaba un archivo llamado wp-comments-posts.php (diseñado para confundirse visualmente con el archivo legítimo de WordPress) y lo usaba para inyectar un bloque masivo de PHP en wp-config.php. Hasta acá, nada que no hayamos visto antes.

Lo distinto es cómo el malware resolvía su servidor de comando y control. En vez de hardcodear un dominio, consultaba smart contracts en la blockchain de Ethereum a través de endpoints RPC públicos. La dirección del servidor C2 vivía en la blockchain, y el atacante podía actualizarla sin tocar los sitios infectados ni registrar un nuevo dominio.

¿Por qué importa esto? Porque los takedowns de dominio tradicionales, que son el mecanismo estándar para cortar la infraestructura de un botnet, no funcionan cuando la dirección C2 está en una blockchain descentralizada. No hay un registrador al que puedas llamar para bajar el dominio. No hay un hosting que puedas contactar. La blockchain es inmutable y pública por diseño.

Es la primera vez que se documenta este vector a esta escala en ataques contra WordPress. Y la «innovación» técnica tiene un problema obvio para los defensores: las herramientas de detección no estaban buscando consultas a RPC endpoints de Ethereum desde un servidor web.

El spam SEO invisible: cloaking para Googlebot

Ponele que tenés un sitio de seguridad WordPress. Todo se ve normal desde tu panel, ninguna queja de usuarios, performance OK. Mientras tanto, Google está indexando páginas de casino online y farmacéuticas que viven en tu dominio.

Así funcionaba el payload. El código inyectado en wp-config.php (un bloque de aproximadamente 6KB de PHP ofuscado) detectaba el user-agent del visitante. Si era Googlebot u otro bot de indexación, servía spam de keywords de gambling, cripto y farma. Si era un humano, mostraba el sitio normal. Sin alertas, sin páginas raras visibles, sin nada que vos pudieras ver directamente.

El objetivo era SEO puro: contaminar el perfil de dominio de miles de sitios legítimos para rankear keywords de alto valor en nichos que Google suele penalizar. Los sitios infectados eran usados como escudos para hacer link building y authority laundering.

Cuando WordPress.org forzó la actualización del plugin, el módulo descargador quedó inactivo. Pero el código ya estaba en wp-config.php, y actualizando el plugin no lo limpiás. Hay que hacerlo a mano.

Cómo detectar si tu sitio fue comprometido

Si instalaste alguno de estos plugins entre agosto de 2025 y el 7 de abril de 2026, revisá.

Revisar wp-config.php manualmente

Abrí el archivo y comparalo con el wp-config-sample.php que viene en tu instalación de WordPress. Cualquier bloque de código que no sea configuración de base de datos, prefijo de tabla, o constants propios de tu instalación es sospechoso. El malware inyecta un bloque largo y ofuscado, generalmente hacia el final del archivo o intercalado en el medio.

Buscar wp-comments-posts.php

Ese archivo no existe en una instalación limpia de WordPress. El archivo legítimo es wp-comments-post.php (sin la «s» en «posts»). Si encontrás wp-comments-posts.php en la raíz de tu instalación, es malware. Borralo.

Usar un scanner

Wordfence en modo scan completo o Sucuri SiteCheck pueden detectar el código inyectado en wp-config.php si ya tienen las firmas actualizadas. Según Patchstack, que cubrió el incidente en detalle, sus reglas de WAF ya bloquean los patrones conocidos del ataque.

Pasos para limpiar el backdoor manualmente

Antes de tocar nada: guardá las credenciales de la base de datos que están en wp-config.php (DB_NAME, DB_USER, DB_PASSWORD, DB_HOST). Las vas a necesitar cuando regeneres el archivo.

• Paso 1: Descargá una copia limpia de wp-config-sample.php de wordpress.org para tu versión de WordPress.
• Paso 2: Abrí tu wp-config.php actual y encontrá todo el código que no sea configuración legítima. Si hay bloques de código PHP ofuscado con funciones como eval(), base64_decode(), o llamadas a curl, esos son los candidatos.
• Paso 3: Eliminá el código malicioso. Si tenés dudas sobre qué es legítimo y qué no, reconstruí el archivo desde cero usando el sample y metiendo solo tus credenciales y constants propios.
• Paso 4: Buscá y eliminá wp-comments-posts.php si existe.
• Paso 5: Revisá el resto de los archivos del tema activo y de cualquier plugin de la lista comprometida. El malware a veces deja copias adicionales.
• Paso 6: Cambiá todas las contraseñas: base de datos, wp-admin, FTP, hosting. Si usás donweb.com o cualquier otro proveedor de hosting, accedé al panel y regenerá el password de la DB también desde ahí.
• Paso 7: Forzá Google a reindexar el sitio desde Search Console para que deje de asociar tu dominio con las páginas de spam.

Si tenés un backup de antes de agosto de 2025, ese es el camino más seguro. Restaurá desde ahí y actualizá todo lo que haya cambiado desde entonces.

Vulnerabilidades estructurales de WordPress que lo hicieron posible

El ataque no explotó un bug de seguridad técnico. Explotó políticas inexistentes.

Según el análisis de The Next Web, WordPress no tiene mecanismo para revisar transferencias de propiedad de plugins, no exige code signing para actualizaciones, y no requiere 2FA para cuentas de desarrollador en el repositorio oficial. Cualquiera puede comprar un plugin con 100.000 instalaciones activas y subir una actualización comprometida sin que nadie revise el código.

Esto no es un problema nuevo. La comunidad de seguridad WordPress lleva años señalándolo. El problema es que resolverlo requiere decisiones que la Fundación WordPress no ha querido tomar porque complican el proceso de publicación para desarrolladores legítimos (que muchas veces son individuos o equipos pequeños). El balance entre facilidad de contribución y seguridad está roto, y este ataque lo demostró a escala.

Qué está confirmado / Qué no está claro todavía

Errores comunes al responder a este incidente

Error 1: Pensar que actualizar el plugin alcanza. WordPress.org forzó una actualización que desactivó el módulo descargador, pero el código ya inyectado en wp-config.php no se limpia automáticamente. El plugin actualizado y el archivo de configuración infectado coexisten. Tenés que limpiar manualmente o desde un backup.

Error 2: Creer que si el sitio «se ve bien» no hay problema. Todo el punto del cloaking es ese: el sitio se ve normal para vos y para tus visitantes. Solo Googlebot ve el spam. Para cuando notás que Google está indexando páginas raras, el daño al SEO del dominio puede llevar meses en revertirse.

Error 3: Desactivar el plugin sin borrarlo. Un plugin desactivado en WordPress no ejecuta su código en el frontend, pero los archivos siguen ahí. Si el malware dejó archivos adicionales fuera del directorio del plugin (como hizo con wp-comments-posts.php), seguís comprometido. Borrá el plugin y revisá el sistema de archivos completo.

Preguntas Frecuentes

¿Qué es un ataque de supply chain en WordPress?

Es un ataque donde el código malicioso se introduce en el software antes de que llegue al usuario final, comprometiendo la cadena de distribución. En este caso, el atacante compró plugins legítimos en el marketplace Flippa y les inyectó backdoors, que luego se distribuyeron como actualizaciones normales a todos los sitios que usaban esos plugins.

¿Cuáles son los plugins WordPress comprometidos en abril de 2026?

WordPress.org cerró 31 plugins del autor identificado como «Essential Plugin» el 7 de abril de 2026. Countdown Timer Ultimate y Widget Logic son los más documentados. Si instalaste cualquier plugin de ese portfolio entre agosto de 2025 y esa fecha, considerá tu sitio potencialmente comprometido y revisá wp-config.php manualmente.

¿Por qué el atacante usó Ethereum como C2?

Porque la blockchain de Ethereum es descentralizada e inmutable: no hay registrador que pueda bajar el dominio, no hay hosting que pueda cortar el servidor. El atacante almacenó la dirección del servidor C2 en un smart contract, y el malware la resolvía consultando endpoints RPC públicos. Podía cambiar la dirección del servidor sin tocar los sitios infectados, haciendo inefectivos los métodos tradicionales de takedown.

¿Cómo limpiar un backdoor en wp-config.php?

Guardá primero las credenciales de base de datos que están en el archivo. Luego identificá y eliminá cualquier bloque de código PHP que no sea configuración legítima: credentials, prefijo de tabla, constants propios. Si tenés dudas, reconstruí el archivo desde wp-config-sample.php e insertá solo los valores necesarios. Después, buscá y eliminá el archivo wp-comments-posts.php si existe en tu instalación.

¿Cómo saber si mis plugins de WordPress están infectados?

Verificá si instalaste algún plugin del portfolio Essential Plugin entre agosto de 2025 y el 7 de abril de 2026. Revisá wp-config.php buscando código ofuscado o funciones como eval() y base64_decode() que no pusiste vos. Buscá el archivo wp-comments-posts.php en la raíz de tu WordPress (no existe en instalaciones limpias). Un scan con Wordfence o Sucuri con firmas actualizadas también puede detectarlo.

Conclusión

Lo que cambió con este ataque no es la técnica del backdoor: eso existe hace décadas. Lo que cambió es la escala y la metodología. Alguien invirtió una cantidad considerable de dinero (seis cifras en dólares), esperó ocho meses para no levantar sospechas, y usó infraestructura blockchain para hacer el ataque resistente a los métodos de defensa estándar. Eso es operación de nivel profesional, no script kiddie.

WordPress como plataforma tiene un problema estructural que este incidente expuso con claridad: la confianza en el repositorio oficial de plugins es total, automática, y sin verificación de ownership. Hasta que eso cambie, cada plugin que comprás es también un vector de riesgo si su dueño original decide venderlo.

Lo concreto que podés hacer ahora: auditá qué plugins tenés instalados, de quién son, y cuándo fue la última transferencia de propiedad. Desactivá las actualizaciones automáticas si tu flujo de trabajo lo permite, y revisá manualmente antes de aplicarlas. Y si alguno de tus sitios usó cualquier plugin del portfolio Essential Plugin en los últimos meses, no des por limpio el sitio hasta que hayas revisado wp-config.php línea por línea.

Fuentes

• Anchor Host – Someone Bought 30 WordPress Plugins and Planted a Backdoor in All of Them
• Patchstack – Critical Supply Chain Compromise on 20+ Plugins by EssentialPlugin
• The Next Web – 30+ WordPress plugins bought on Flippa and backdoored in supply chain attack
• TechCrunch – Someone planted backdoors in dozens of WordPress plugins
• WPBeginner – How to Find a Backdoor in a Hacked WordPress Site and Fix It