El 7 de abril de 2026, WordPress.org cerró de un plumazo 31 plugins que compartían el mismo dueño. ¿El motivo? Un backdoor plantado ocho meses antes que estuvo dormido hasta que alguien apretó el botón rojo. Cuando despertó, más de 20.000 sitios ya estaban sirviendo spam de gambling y cripto a Googlebot sin que los dueños vieran nada raro.
Un ataque de supply chain a plugins WordPress es una infección donde el malware no entra por una vulnerabilidad del sitio, sino que ya viene de fábrica dentro de un plugin legítimo porque los atacantes tomaron el control del código fuente antes de que llegue a tus manos. En este caso, compraron el portfolio entero de una empresa, inyectaron el backdoor, y esperaron.
En 30 segundos
- 31 plugins fueron cerrados por WordPress.org el 7 de abril de 2026, todos del portfolio Essential Plugin (antes WP Online Support).
- Más de 20.000 sitios activos quedaron comprometidos, con un backdoor alojado en wp-config.php.
- El ataque usó cloaking: solo Googlebot veía el spam de gambling, cripto y pharma; los humanos veían el sitio normal.
- Actualizar el plugin no limpia nada: el malware está fuera del directorio del plugin, metido directo en wp-config.php.
- Los atacantes usaron smart contracts de Ethereum como C2, haciendo casi imposible tumbar la infraestructura de comando.
¿Cuántos sitios fueron afectados por el ataque a plugins de WordPress?
Más de 20.000 sitios activos, según los reportes de los investigadores que destriparon el malware. WordPress.org actuó el 7 de abril de 2026 cerrando los 31 plugins comprometidos de una sola vez — algo poco común, porque normalmente los cierres son puntuales, no en lote.
El alcance fue global. No discriminó nicho, idioma ni geografía. Si tenías instalado cualquiera de esos plugins, tu wp-config.php probablemente ya tenía 6 KB de PHP ofuscado esperando instrucciones. Los plugins cerrados cubrían funcionalidades variadas: desde sliders y formularios hasta «helpers» genéricos que muchos desarrolladores usaban como dependencia en temas y otros plugins. Eso amplificó el radio de infección de una manera bastante difícil de mapear al principio.
¿Cuántos sitios más quedaron expuestos indirectamente? Imposible saberlo con precisión, pero habría que asumir que cualquier instalación donde estos plugins funcionaban como dependencia también quedó tocada.
¿Cómo los atacantes compraron plugins en Flippa y plantaron un backdoor?
Acá es donde la cosa se pone interesante — y preocupante. A principios de 2025, alguien compró el portfolio completo de Essential Plugin (conocido antes como WP Online Support) a través de Flippa, un marketplace donde se venden sitios web, dominios y… sí, plugins de WordPress. La transacción fue por una suma de seis cifras en dólares (no se reveló el monto exacto, pero hablamos de al menos USD 100.000).
El nuevo dueño — cuya identidad sigue sin estar clara, y probablemente nunca lo esté — tuvo acceso total al código fuente, a los repositorios SVN de WordPress.org y a las actualizaciones automáticas. En agosto de 2025 inyectaron el backdoor en una actualización que parecía rutinaria. Y después, silencio absoluto durante ocho meses. Te puede servir nuestra cobertura de nuestra guía completa sobre vulnerabilidades CVE.
Recién entre el 5 y 6 de abril de 2026 activaron la carga maliciosa. Ocho meses de latencia. Eso es disciplina operativa, no improvisación. El backdoor se alojaba en wp-config.php — fuera del directorio del plugin — y usaba smart contracts de Ethereum como mecanismo de comando y control. Así, no había un servidor central que tumbar; la infraestructura de ataque vivía en la blockchain.
¿Por qué el malware solo afectaba a Googlebot y no a los dueños del sitio?
Porque si el dueño ve el spam, lo limpia. Si no lo ve, el negocio sigue funcionando. Simple y efectivo.
La técnica se llama cloaking, y en este caso estaba implementada con precisión quirúrgica. El código ofuscado en wp-config.php inspeccionaba el user-agent de cada visita. Si detectaba que era Googlebot (o cualquier crawler de motores de búsqueda relevante), reescribía el contenido del sitio al vuelo: páginas de gambling, enlaces a exchanges de cripto dudosos, y farmacéuticas online — el combo completo de SEO spam. Si el visitante era un humano, el sitio se mostraba exactamente igual que siempre.
El resultado: miles de sitios legítimos rankeando para términos de casino y Viagra sin que sus dueños tuvieran la menor idea. Google indexaba el spam, los atacantes cobraban comisiones por tráfico o afiliación, y el administrador del sitio recién se enteraba cuando alguien le decía «che, tu sitio sale en búsquedas de ruleta online».
¿Y cómo se comunicaba el backdoor con sus amos sin levantar sospechas? Usaba smart contracts de Ethereum como C2 (command and control). En vez de llamar a un dominio sospechoso que cualquiera podía reportar y tumbar, el código consultaba datos alojados en la blockchain. Tumbar eso es imposible sin tumbar Ethereum entero (spoiler: no vas a tumbar Ethereum).
¿Qué plugins específicos estaban infectados y cómo identificarlos?
Los 31 plugins pertenecían al portfolio Essential Plugin, antes operado por WP Online Support. WordPress.org los cerró todos de forma simultánea el 7 de abril de 2026. Cuando un plugin es cerrado, en tu panel de WordPress aparece un aviso explícito: «Este plugin ha sido cerrado y ya no está disponible para descargas».
Si ves ese aviso en alguno de tus plugins, no alcanza con desactivarlo. El daño ya está hecho — o está latente, que es peor. La lista completa incluye plugins de sliders, formularios de contacto, optimizadores de rendimiento, y utilidades para desarrolladores. El patrón común: todos compartían el mismo dueño corporativo, lo que explica por qué cayeron juntos. Esto se conecta con lo que analizamos en cómo un WAF puede proteger tu WordPress.
Para revisar si estás afectado, entrá a tu panel de WordPress, andá a Plugins > Plugins instalados, y buscá cualquier plugin que muestre el estado «cerrado». Si encontrás uno, pasá directamente a la sección de limpieza manual — no pierdas tiempo «investigando».
¿Cómo limpiar manualmente el backdoor de wp-config.php?
El backdoor no está en el plugin. Está en wp-config.php, el archivo más sensible de cualquier instalación WordPress. Por eso desinstalar o actualizar el plugin no sirve de nada: el código malicioso está fuera de su alcance.
Pasos para limpiarlo:
- Abrí wp-config.php por FTP, SSH o desde el administrador de archivos de tu hosting.
- Buscá un bloque de PHP ofuscado de aproximadamente 6 KB — vas a notar cadenas largas en base64, variables con nombres sin sentido, y funciones eval() o similares. No tiene nada que ver con las constantes habituales de WordPress.
- Eliminá ese bloque completo, desde la primera línea sospechosa hasta la última. Si tenés dudas, compará con un wp-config.php limpio de una instalación fresca de WordPress.
- Verificá que no queden restos buscando funciones como
file_get_contents,curl_execo referencias a direcciones Ethereum dentro del archivo. - Cambiá las claves de seguridad (las salts) y las contraseñas de la base de datos por las dudas — el atacante tuvo acceso de lectura y escritura a tu configuración.
Si no te sentís cómodo haciendo esto, buscá a alguien que sí. Tocar wp-config.php sin saber lo que hacés puede dejar tu sitio fuera de línea. Dicho esto, dejar el backdoor es bastante peor.
¿Por qué las actualizaciones automáticas de plugins no eliminan este malware?
Porque el malware nunca estuvo en el plugin. Está en wp-config.php.
Cuando WordPress.org cierra un plugin, fuerza una actualización que esencialmente lo desactiva o lo reemplaza por una versión limpia (si el equipo de seguridad publicó una). Pero ese proceso toca únicamente los archivos dentro de /wp-content/plugins/nombre-del-plugin/. El wp-config.php está en la raíz de tu instalación — fuera de la jurisdicción de cualquier update routine de plugins.
Peor aún: durante los ocho meses de latencia, el plugin funcionaba con normalidad y se actualizaba sin problemas. El código malicioso en wp-config.php simplemente esperaba. Cuando llegó la orden por smart contract el 5 de abril de 2026, se activó sin que ninguna actualización de seguridad pudiera prevenirlo — porque las actualizaciones de seguridad no escanean wp-config.php buscando código ofuscado. No es su trabajo.
¿Qué cambios estructurales necesita WordPress para evitar ataques similares?
Este ataque expuso varias costuras del ecosistema WordPress que vienen pidiendo refuerzo hace años. No es la primera vez que pasa algo así (¿alguien se acuerda de los themes piratas con backdoors?), pero la escala y la sofisticación de este caso obligan a replantear algunas cosas.
- Code-signing obligatorio: que cada actualización esté firmada criptográficamente y WordPress verifique la firma antes de instalarla. Si el plugin cambió de dueño sin el proceso adecuado, la firma no coincide y la actualización se frena.
- 2FA forzoso en cuentas con permisos de commit: el atacante accedió al repositorio SVN legítimo porque compró la empresa. Pero si WordPress.org exigiera verificación de identidad reforzada ante cambios de titularidad, el proceso no sería tan opaco.
- Revisión de código obligatoria tras cambio de propiedad: si un plugin cambia de dueño, el nuevo código debería pasar por un review antes de publicarse. Hoy eso no existe.
- Notificación a administradores cuando cambia el dueño de un plugin instalado: si instalaste un plugin de «WP Online Support» y de repente pasa a ser de «Essential Plugin» (o de un tercero anónimo), deberías recibir un aviso en el panel. No un email que ignorás — un aviso visible.
- Escaneo de integridad en archivos críticos: WordPress podría ofrecer un chequeo básico de wp-config.php y otros archivos fuera de
/wp-contentque detecte código ofuscado sospechoso. No es trivial, pero tampoco imposible.
La pregunta de fondo es si el modelo de «cualquiera puede publicar un plugin y cualquiera puede comprarlo» sigue siendo viable sin controles adicionales. La respuesta corta: sí, pero con estos refuerzos. La larga involucra un debate sobre gobernanza del repositorio que excede este artículo. Lo explicamos a fondo en la protección contra ataques DDoS en WordPress.
Tabla comparativa: ataque tradicional vs. ataque supply chain
| Característica | Ataque tradicional | Ataque supply chain (este caso) |
|---|---|---|
| Punto de entrada | Vulnerabilidad en el sitio o plugin | Código malicioso inyectado por el dueño del plugin |
| Detección por el dueño | Posible (escaneos, anomalías) | Casi imposible (cloaking a Googlebot) |
| Latencia | Inmediata o días | 8 meses (agosto 2025 a abril 2026) |
| Ubicación del malware | Dentro del plugin o uploads | wp-config.php (fuera del alcance del plugin) |
| C2 (comando y control) | Dominios o IPs tumbables | Smart contracts de Ethereum (imposible de tumbar) |
| Limpieza | Desinstalar/actualizar plugin | Edición manual de wp-config.php |
Qué significa para empresas y equipos en Latinoamérica
En Latinoamérica, donde una parte enorme del ecosistema web corre sobre WordPress y muchas agencias gestionan decenas o cientos de sitios de clientes, este ataque es una pesadilla logística. Revisar wp-config.php en 50 instalaciones no es un martes cualquiera — es un proyecto de varios días.
Además, el uso de smart contracts como C2 cambia el tablero. Ya no alcanza con bloquear IPs sospechosas o reportar dominios. La infraestructura de ataque es descentralizada por definición. Si tu hosting no te da acceso SSH o al wp-config.php desde el panel, estás en problemas — y varios proveedores económicos limitan ese acceso. (Si estás buscando un hosting que te dé control total sobre tus archivos sin vueltas, en donweb.com tienen planes con acceso SSH y backups automáticos que al menos te permiten reaccionar rápido cuando estas cosas pasan.)
El costo real no es el hackeo en sí — es el tiempo de limpieza, el daño al SEO (Google te puede penalizar por el spam que ni sabías que estabas sirviendo), y la pérdida de confianza de los clientes cuando les explicás que su sitio estuvo vendiendo Viagra a escondidas durante semanas.
Qué está confirmado y qué no
| Confirmado | Pendiente |
|---|---|
| 31 plugins cerrados por WordPress.org el 7 de abril de 2026 | Monto exacto de la compra del portfolio en Flippa (solo se sabe «seis cifras en USD») |
| Más de 20.000 sitios activos comprometidos | Identidad del comprador de los plugins |
| Backdoor inyectado en agosto de 2025, activado 5-6 de abril de 2026 | Cantidad de sitios afectados indirectamente por dependencias |
| Malware alojado en wp-config.php, no en el directorio del plugin | Si hubo variantes del malware en otros plugins no relacionados |
| Cloaking basado en user-agent (Googlebot veía spam, humanos no) | Impacto total en rankings de Google de los sitios afectados |
| Uso de smart contracts de Ethereum como C2 | Si los atacantes monetizaron solo con SEO spam o también con robo de datos |
Errores comunes al enfrentar este tipo de infección
Asumir que con desinstalar el plugin alcanza
El error más peligroso. El backdoor está en wp-config.php. Podés borrar el plugin entero y el malware sigue ahí, funcional y esperando instrucciones. La desinstalación solo saca el módulo descargador; el payload persiste.
Confiar ciegamente en que «a mí no me va a pasar»
El ataque no discriminó nicho, tráfico ni popularidad del sitio. Si tenías uno de los 31 plugins instalado, estás en la lista. No importa si tu sitio es institucional, un blog personal o un ecommerce chico — los atacantes apuntaban al volumen agregado, no a víctimas específicas. Revisar lleva 10 minutos. No revisar te puede costar el SEO de meses.
Pensar que un plugin «cerrado» es sinónimo de «seguro ahora»
WordPress.org cerró los plugins para que no se descarguen más. Eso frena la propagación hacia nuevos sitios, pero no limpia los que ya están infectados. Cerrar el plugin es como cerrar la puerta del granero después de que los caballos se escaparon — ayuda hacia adelante, no resuelve lo que ya pasó.
Restaurar un backup sin verificar wp-config.php
Si el backdoor se plantó en agosto de 2025 y restaurás un backup de, digamos, noviembre de 2025… acabás de restaurar el backdoor. Tenés que verificar la fecha exacta de inyección y volver a un punto anterior a agosto de 2025, o limpiar manualmente después de restaurar. No hay atajos.
Preguntas Frecuentes
¿Cómo detectar si un plugin de WordPress está infectado con malware?
Revisá si el plugin aparece como «cerrado» en tu panel de WordPress. Luego, inspeccioná wp-config.php en busca de bloques de PHP ofuscado (cadenas base64 largas, funciones eval(), variables sin sentido). También podés buscar tu sitio en Google con términos que nunca usaste — si aparecen resultados de gambling, cripto o farmacéuticas, tenés el backdoor activo. Para más detalles técnicos, mirá asegurar formularios con el plugin WPForms.
¿Qué plugins fueron infectados en el ataque de abril 2026?
Los 31 plugins del portfolio Essential Plugin (anteriormente WP OnlineSupport). WordPress.org los cerró el 7 de abril de 2026. Si tenés un plugin con estado «cerrado» en tu panel y pertenecía a ese grupo, asumí que está comprometido. La lista exacta está disponible en el anuncio oficial de cierre de WordPress.org.
¿Cómo eliminar un backdoor de wp-config.php?
Abrí wp-config.php por FTP o SSH, localizá el bloque de PHP ofuscado (unas 6 KB de código base64 con eval()), y eliminalo por completo. Verificá que no queden referencias a smart contracts de Ethereum. Cambiá las claves de seguridad y las credenciales de base de datos después de la limpieza. No alcanza con actualizar o desinstalar el plugin.
¿Por qué el malware solo se muestra a Googlebot?
Porque usa cloaking: el código en wp-config.php inspecciona el user-agent de cada visita. Si detecta Googlebot u otros crawlers, inyecta spam de gambling y cripto en el contenido. Si el visitante es humano, muestra el sitio normal. El objetivo es que los dueños no detecten la infección mientras Google indexa el spam y genera tráfico o comisiones para los atacantes.
¿Cómo protegerse de ataques supply chain en WordPress?
Usá solo plugins con historial de mantenimiento activo y dueños verificables. Activá actualizaciones automáticas para parches de seguridad. Implementá un sistema de backups que retenga versiones de al menos 12 meses. Revisá wp-config.php y otros archivos críticos cada vez que un plugin instalado cambie de dueño o aparezca como «cerrado». Un firewall como Wordfence o Sucuri ayuda, pero contra un backdoor en wp-config.php con C2 en blockchain, la detección temprana sigue dependiendo de revisión humana.
Conclusión
Este ataque es distinto a lo que veníamos viendo. No es un plugin vulnerable que parcheás y listo — es un plugin deliberadamente convertido en caballo de Troya por sus nuevos dueños, con una latencia de ocho meses y un mecanismo de control que vive en la blockchain. La sofisticación subió varios escalones.
Lo que queda claro es que el modelo de confianza del repositorio de WordPress — «si está en el repo oficial, es seguro» — ya no alcanza. Cambios de propiedad sin revisión de código, falta de notificaciones a administradores, y cero verificación de integridad en archivos críticos como wp-config.php son agujeros que este ataque explotó con precisión quirúrgica.
Si gestionás sitios WordPress, hoy tenés dos tareas: revisar wp-config.php de todas tus instalaciones, y replantearte qué plugins dejás entrar en tu stack. La confianza no se regala más.