Alguien compró 31 plugins de WordPress y metió una puerta trasera en todos. Puede que tu web sea una de ellas.

7 de abril de 2026. El equipo de seguridad de WordPress.org cierra 31 plugins en un solo día.

Todos del mismo autor. Todos con código malicioso. Todos instalados en cientos de miles de webs que, hasta ese martes, funcionaban perfectamente.

Nadie hackeó nada. No hubo brecha de seguridad. No hubo exploit.

El atacante simplemente compró los plugins. Con su tarjeta. En Flippa. Por seis cifras. Público y a la vista de todos.

Esto es la historia de cómo un solo comprador anónimo convirtió 8 años de confianza acumulada en un ataque coordinado con un backdoor que llevaba 8 meses dormido en actualizaciones oficiales antes de que nadie lo detectara. Y de por qué, si tu web está en WordPress, esto debería preocuparte más que cualquier otra noticia de seguridad de este año.

El ataque en 30 segundos

Porque igual has llegado aquí con prisa. Resumen:

• Una empresa india legítima llamada Essential Plugin llevaba 10 años haciendo plugins de WordPress. 31 en total. Cosas como contadores, sliders, galerías, testimonios. Plugins que probablemente has instalado tú o tu anterior desarrollador sin pensarlo.
• Más de 400.000 instalaciones activas en todo el mundo.
• En 2025, el dueño original vendió la empresa en Flippa (el marketplace de webs y negocios online) por seis cifras a un comprador anónimo llamado "Kris".
• Kris heredó el acceso a subir actualizaciones a WordPress.org. Sin preguntas. Sin revisión. Sin notificación a los usuarios.
• Agosto 2025: su primer commit añade un backdoor camuflado en una actualización llamada inocentemente "Check compatibility with WordPress version 6.8.2".
• El backdoor duerme 8 meses.
• 6 de abril de 2026, 04:22 UTC: se activa. Entre las 04:22 y las 11:06 de la mañana, miles de webs en WordPress son infectadas silenciosamente.
• El malware solo muestra el spam a Googlebot. Los dueños de las webs no ven nada. Todo parece normal. Pero Google indexa sus dominios con páginas de spam, enlaces a casinos y redirecciones fraudulentas.
• Y la guinda: el servidor de control del malware no vive en un dominio normal. Vive en un smart contract de Ethereum. Imposible de tirar abajo.

¿Te parece una novela de ciberpunk? Pues es la historia real reconstruida por Austin Ginder, fundador de Anchor Hosting, a partir de backups diarios y 939 snapshots del plugin a lo largo de los años. Todo está documentado. Vamos a los detalles, porque aquí es donde se pone interesante.

Acto 1: un negocio legítimo con una década de historia

Febrero 2015. Tres desarrolladores indios — Minesh Shah, Anoop Ranawat y Pratik Jain — registran el dominio wponlinesupport.com y empiezan a publicar plugins gratuitos en el repositorio oficial de WordPress.

Octubre 2016: publican Countdown Timer Ultimate. Un contador regresivo. Funciona. La gente lo instala.

Los siguientes años hacen lo que hace cualquier negocio de plugins de WordPress: versiones gratuitas en el repositorio oficial (para captar usuarios), versiones premium vendidas desde su propia web (para generar ingresos). Crecen. En 2021 rebrandean a "Essential Plugin" y construyen un portfolio de más de 30 plugins.

Durante una década, nadie tiene ningún problema con ellos. Sus plugins aparecen en tutoriales de WordPress, los recomiendan en foros, los instalan agencias. Son una marca de confianza dentro del ecosistema.

Esta es la parte importante: no era una empresa fantasma. Era un negocio real con productos reales y clientes reales durante 10 años.

La confianza en WordPress no se construye sobre el código. Se construye sobre el nombre del desarrollador. Y los nombres se venden.

Acto 2: la venta en Flippa

Finales de 2024. Los ingresos de Essential Plugin caen un 35-45%. Minesh decide vender.

Lo lista en Flippa, un marketplace público donde cualquiera puede comprar negocios online. Es completamente legal. De hecho, Flippa publicó en julio de 2025 un case study celebrando la venta como un éxito: "Cómo vender un negocio de plugins de WordPress por seis cifras".

El comprador: alguien usando el alias "Kris". Perfil público: background en SEO, crypto y marketing de gambling online.

Ahora para y piensa esto un momento. Un tipo con experiencia en SEO y casinos online compra una empresa con acceso directo a las actualizaciones automáticas de cientos de miles de webs.

¿Saltan alarmas? No. ¿WordPress.org revisa la transferencia? No. ¿Se notifica a los usuarios que "oye, el plugin que tenéis instalado ahora lo lleva otra persona"? No.

Porque WordPress.org no tiene ningún mecanismo para eso. Literalmente ninguno. Compras un plugin, heredas el acceso, y el martes siguiente puedes subir lo que quieras a cientos de miles de webs. Así es como funciona hoy.

Acto 3: el backdoor dormido

12 de mayo de 2025. Se crea la nueva cuenta essentialplugin en WordPress.org.

14-16 de mayo de 2025. Últimos commits de la cuenta original. Se cambian los headers de autor. Transferencia completada.

8 de agosto de 2025. Primer commit de la nueva cuenta. Versión 2.6.7 de Countdown Timer Ultimate. Changelog oficial: "Check compatibility with WordPress version 6.8.2."

Lo que realmente hizo ese commit, según el análisis forense de Ginder:

Añadió 191 líneas de código, incluyendo un backdoor basado en deserialización de PHP. El archivo class-anylc-admin.php pasó de 473 a 664 líneas.

Tres piezas clave:

1. Un método fetch_ver_info() que hace file_get_contents() a un servidor del atacante y pasa la respuesta directamente a @unserialize().
2. Un método version_info_clean() que ejecuta @$clean($this->version_cache, $this->changelog) — donde $clean, $version_cache y $changelog vienen todos del servidor remoto.
3. Un endpoint REST API sin autenticación con permission_callback: __return_true.

Traducción al español no-técnico: el servidor remoto controla qué función PHP se ejecuta en tu servidor y con qué argumentos. Es una ejecución arbitraria de código. Total. Sin autenticación. Sin que el dueño de la web sepa que existe.

Y aquí es donde entra la parte paciente del atacante. El backdoor quedó dormido 8 meses. Sin hacer nada. Sin dar señales. Solo esperando.

¿Por qué? Porque si activas el backdoor inmediatamente, algún investigador de seguridad lo detecta en una semana y todo se quema. Si esperas 8 meses, durante ese tiempo:

• El plugin se sigue instalando en webs nuevas.
• Las webs que lo tenían instaladas lo van actualizando a la versión "con backdoor" creyendo que es una actualización normal.
• Tu superficie de ataque crece mes a mes.

Mientras tanto, en agosto de 2025, se actualizaba el WHOIS de essentialplugin.com a nombre de "Kim Schmidt" en Zurich, con una dirección de ProtonMail. Nadie se dio cuenta. Nadie miraba.

Acto 4: el despertar

6 de abril de 2026, 04:22 UTC. El servidor del atacante empieza a repartir payloads.

Ginder lo reconstruyó exactamente gracias a backups diarios con restic. Comparó el tamaño del archivo wp-config.php en 8 snapshots distintos:

Fecha	Tamaño de wp-config.php
1 Nov 2025	3.346 bytes
1 Ene 2026	3.346 bytes
1 Mar 2026	3.345 bytes
5 Abr 2026	3.345 bytes
6 Abr 2026, 04:22 UTC	3.345 bytes
7 Abr 2026, 04:21 UTC	9.540 bytes

Una ventana de 6 horas y 44 minutos. Durante esa madrugada, el backdoor descargó un archivo falso llamado wp-comments-posts.php (nota la "s" extra — camuflado como el archivo real wp-comments-post.php de WordPress core) e inyectó 6KB de PHP directamente en wp-config.php, el archivo más crítico de cualquier web WordPress.

¿Qué hacía el código inyectado?

Tres cosas, todas simultáneamente:

1. SEO spam invisible. El código comprobaba si quien visitaba la web era Googlebot. Si eras un visitante normal, no veías nada. Si eras Google, recibías páginas inyectadas con enlaces a casinos, redirecciones a sitios fraudulentos y backlinks hacia la red de SEO del atacante. Tu web, a ojos de Google, se convertía en una granja de enlaces de spam sin que tú lo supieras.

2. Redirecciones dirigidas. Ciertas URLs de tu propia web redirigían a dominios controlados por el atacante cuando se accedía desde fuentes específicas.

3. Control remoto total. El atacante podía ejecutar código PHP arbitrario en tu servidor en cualquier momento.

Pero la parte más técnicamente impresionante — y aterradora — es cómo el malware encontraba su servidor de control.

El smart contract como servidor de control

Un malware tradicional tiene un problema: su servidor de control vive en un dominio normal. Y los dominios se pueden tirar abajo. Empresas como Cloudflare, registradores de dominios y autoridades pueden suspender el dominio malicioso y, de repente, el malware queda "huérfano". Sin poder recibir órdenes.

Los autores de este malware lo resolvieron de forma creativa. En palabras de Ginder:

Resolvía su dominio C2 a través de un smart contract de Ethereum, consultando endpoints públicos RPC de la blockchain. Los takedowns tradicionales de dominio no funcionarían porque el atacante podría actualizar el smart contract para apuntar a un nuevo dominio en cualquier momento.

Traducción: el "dónde se conecta el malware" está escrito en la blockchain de Ethereum. El malware consulta el smart contract, el smart contract le dice "conéctate a este dominio", y el atacante puede cambiar ese dominio en cualquier momento actualizando el smart contract. No hay dominio fijo que tirar abajo. No hay servidor central que incautar.

Para tirar eso abajo tendrías que, literalmente, apagar Ethereum. Y eso no va a pasar.

Esto es un antes y un después. En los próximos años, prepárate para ver esta técnica aplicada a muchos más tipos de malware. Las herramientas tradicionales del FBI y equivalentes de tirar dominios abajo se quedan obsoletas cuando el dominio se resuelve desde una blockchain inmutable.

Acto 5: la lista de los 31

El 7 de abril, WordPress.org cierra los 31 plugins. Aquí está la lista completa según el análisis de Austin Ginder. Si tienes alguno de estos instalado, bórralo ya:

• Accordion and Accordion Slider
• Album and Image Gallery Plus Lightbox
• Audio Player with Playlist Ultimate
• Blog Designer for Post and Widget
• Countdown Timer Ultimate
• Featured Post Creative
• Footer Mega Grid Columns
• Hero Banner Ultimate
• HTML5 VideoGallery Plus Player
• Meta Slider and Carousel with Lightbox
• Popup Anything on Click
• Portfolio and Projects
• Post Category Image with Grid and Slider
• Post Grid and Filter Ultimate
• Preloader for Website
• Product Categories Designs for WooCommerce
• Responsive WP FAQ with Category
• SlidersPack – All in One Image Sliders
• SP News And Widget
• Styles for WP PageNavi – Addon
• Ticker Ultimate
• Timeline and History Slider
• Woo Product Slider and Carousel with Category
• WP Blog and Widgets
• WP Featured Content and Slider
• WP Logo Showcase Responsive Slider and Carousel
• WP Responsive Recent Post Slider
• WP Slick Slider and Image Carousel
• WP Team Showcase and Slider
• WP Testimonial with Widget
• WP Trending Post Slider and Widget

Mira esa lista con atención. Son plugins absolutamente normales. De los que cualquier desarrollador freelance instalaría para un cliente sin pensarlo dos veces. Contadores regresivos, sliders, galerías, testimonios. Son los plugins de los que está hecho WordPress.

Ese es el punto. El atacante no eligió plugins raros ni nicho. Eligió los más útiles, los más instalados y los más aburridos. Porque nadie audita un plugin de contador regresivo.

WordPress.org intentó arreglarlo, pero solo a medias

El 8 de abril, WordPress.org forzó una actualización automática a la versión 2.6.9.1 de los plugins. ¿Qué hace esa actualización?

Añade la línea return; al principio de las funciones maliciosas. Las desactiva. Pero no elimina el código del plugin. Sigue ahí. Solo desactivado.

Y más importante: la actualización forzada no tocó wp-config.php. La inyección de SEO spam seguía activa, sirviendo contenido oculto a Googlebot.

Es decir: WordPress.org te "arregló" el plugin, pero si tu web ya había sido infectada en las 6 horas del 6 de abril, tu wp-config.php sigue comprometido. Tu web sigue sirviendo spam a Google. Y tú no te has enterado.

¿Cuántas webs de las infectadas crees que han limpiado ya su wp-config.php? Sé realista. La respuesta es "muy pocas". Y como el spam solo es visible para Googlebot, esas webs van a seguir siendo penalizadas en búsquedas durante meses sin que sus dueños sepan por qué.

El problema no es este ataque. El problema es el modelo.

Ahora viene la parte incómoda. Porque si te quedas pensando que esto es un incidente aislado, un tipo malo que hizo una cosa mala, no has entendido nada.

Esto ya había pasado antes. Exactamente igual.

En 2017, un comprador con el alias "Daley Tias" compró el plugin Display Widgets (200.000 instalaciones) por 15.000 dólares e inyectó spam de préstamos rápidos. Ese mismo comprador comprometió al menos 9 plugins más usando el mismo método.

2017–2026: nueve años entre ataques. El mismo modus operandi. La misma puerta abierta. Y en nueve años, WordPress.org no ha añadido ni un solo control sobre transferencias de ownership de plugins.

Ahora suma los números del ecosistema. Según los últimos datos de Patchstack:

• En 2025, el 91% de las vulnerabilidades nuevas se encontraron en plugins. Un 9% en temas. Solo 6 en el core, todas de baja prioridad.
• En 2025 se registraron 11.334 vulnerabilidades nuevas de WordPress, la cifra más alta de la historia. Un aumento del 42% año a año.
• La mediana de tiempo entre que se publica una vulnerabilidad y es explotada masivamente: 5 horas.
• El 92% de las brechas exitosas de WordPress en 2025 vinieron de plugins o temas. No del core.
• En diciembre de 2025, más de 150 plugins fueron retirados del repositorio oficial por problemas de seguridad sin parchear o por abandono del desarrollador.

Traducción: el core de WordPress es bastante seguro. El problema son los plugins. Y los plugins son el 99% de por qué usas WordPress. Sin plugins, WordPress es un blog de 2005.

WordPress es seguro. Su core es seguro. El problema es que WordPress sin plugins no hace prácticamente nada, y cada plugin es código de un tercero que se ejecuta en tu servidor con permisos totales.

Por qué esto no puede pasar en Next.js

Esta es la parte donde normalmente viene el autobombo comercial. Me lo voy a saltar parcialmente porque la diferencia técnica es real y merece la pena entenderla.

Una web hecha en Next.js (el framework que usamos nosotros para construir webs a medida) no tiene "plugins" en el sentido de WordPress. Tiene dependencias, que es algo diferente y mejor.

Diferencias clave:

1. Las dependencias se congelan. Cuando construyes una web en Next.js, las versiones de las dependencias quedan fijadas en un archivo (package-lock.json). La web compila con esas versiones exactas. Si alguien actualiza una dependencia dentro del ecosistema, tu web no la descarga automáticamente. Sigue funcionando con la versión que ya tenía. Tú eliges cuándo actualizar — y para hacerlo, hay que volver a construir y desplegar la web, un proceso que un desarrollador revisa.

2. El build es estático. Muchas webs en Next.js (incluidas todas las que hacemos en LPB Digital para PYMEs) se pre-compilan en HTML estático. Eso significa que, en producción, no hay código ejecutándose dinámicamente en el servidor para la mayoría de las páginas. No hay wp-config.php en el que inyectar nada. Literalmente no hay "tu servidor" vulnerable: las páginas son archivos HTML servidos desde un CDN.

3. No hay auto-updates automáticos. En WordPress, una actualización que sube el autor del plugin aparece automáticamente en tu admin. En Next.js, nada se actualiza sin que un desarrollador lo haga conscientemente, lo pruebe en un entorno de staging y lo despliegue. El ataque de Essential Plugin habría sido imposible en nuestro flujo de trabajo porque no somos víctimas pasivas de las actualizaciones que sube otra persona.

4. Control total del código. Cuando hacemos una web a medida, todo el código existe para hacer lo que esa web necesita. Nada más. Si usamos una dependencia, la revisamos. Si no hace falta, no está. Nunca vas a tener 25 "plugins" que hacen cosas que no te hacen falta pero que están ahí porque el tema comercial los trae de serie.

Cuando ves las cifras del párrafo anterior y las comparas con esto, empiezas a entender por qué las grandes empresas han salido masivamente de WordPress en los últimos años. No es moda. Es que el modelo de seguridad de WordPress está roto de base, y parchearlo con plugins de seguridad (que son, también, más plugins) no arregla el problema, lo amplía.

Lo que deberías hacer ahora mismo

Si tu web está en WordPress, y aunque no tengas ninguno de los 31 plugins de la lista:

1. Revisa tus plugins. Entra en /wp-admin/plugins.php. Borra todo lo que no estés usando activamente. Cada plugin inactivo sigue siendo código en tu servidor, y si el desarrollador lo abandona, tu web queda expuesta permanentemente.

2. Investiga quién desarrolla cada plugin que usas. ¿Sabes quién hizo el plugin de "cookies RGPD" que tienes instalado? ¿Sigue activo? ¿Cuándo fue la última actualización? Si un plugin tuyo lleva más de un año sin actualizarse, considéralo abandonado y busca alternativas.

3. Mira tu wp-config.php. Si tu web está en un hosting donde puedas acceder por FTP o SSH, entra y mira el tamaño de wp-config.php. Una instalación limpia tiene entre 3 y 4KB. Si el tuyo pesa significativamente más, mira el contenido. Si ves código PHP que parece hacer peticiones a servidores externos, has sido infectado.

4. Considera si WordPress sigue siendo la opción correcta para tu negocio. No digo que cambies mañana — digo que pares a pensarlo. Si tu web es un activo de negocio, y no solo un blog, las matemáticas de riesgo cambian. Una web en WordPress es barata de hacer pero tiene un coste oculto permanente en mantenimiento, parcheado y riesgo. Hicimos una comparativa honesta entre WordPress y web a medida que cubre esto en detalle.

El remate

Hay una frase que se usa mucho cuando hablamos de por qué los sitemas abiertos tienen tantos problemas de seguridad: "con suficientes ojos, todos los bugs son superficiales". Es de Eric Raymond. Es bonita. Y es falsa.

Essential Plugin tuvo 8 meses con código malicioso subido al repositorio oficial de WordPress. 191 líneas de código que llamaban a unserialize() con datos remotos. Cualquier auditor de seguridad con experiencia lo habría detectado en 10 minutos.

Durante 8 meses, nadie miró. Porque nadie mira los plugins de contadores regresivos. Porque hay 64.000 plugins en el repositorio oficial y miles de commits al día. Porque la infraestructura de revisión no existe a esa escala.

El atacante entendió eso perfectamente. Por eso compró 31 plugins aburridos en lugar de hackear uno popular. Porque los plugins aburridos son los que nadie mira.

Y ahora, mientras lees esto, probablemente haya otros 5 o 10 plugins con el mismo patrón esperando su momento. Comprados por alguien con background en SEO y casinos. Con el backdoor dormido. Esperando el martes correcto para activarse.

La próxima vez no estaremos hablando de 31 plugins. Estaremos hablando de 100.

---

En LPB Digital construimos webs en Next.js para PYMEs españolas que valoran su seguridad y rendimiento. Ves la web terminada antes de pagar. Desde 250€ de proyecto inicial + 20€/mes de mantenimiento. Sin plugins, sin superficie de ataque, sin sorpresas el martes a las 4 de la mañana.

Si tienes una web en WordPress y quieres una segunda opinión sobre su estado de seguridad y rendimiento, pídenos un análisis gratuito. Te mandamos un informe con tus plugins, tu puntuación de velocidad y tu exposición — con números, sin humo.

---

Fuentes: Anchor Hosting — el análisis forense completo de Austin Ginder, TechRadar, Patchstack State of WordPress Security 2026.