El 7 de abril de 2026 treinta y un plugins WordPress desaparecieron del repositorio oficial el mismo día. Si tenías alguno instalado, durante ocho meses tu web estuvo enviando spam a Google sin que tú vieras nada raro en el escritorio.
No fue un fallo de programación ni una vulnerabilidad clásica de las que se publican en una base de datos y se parchean en dos semanas, fue otra cosa.
Alguien con dinero compró el catálogo entero de plugins de un desarrollador conocido, heredó sus permisos de WordPress.org y subió una actualización envenenada que llegó a cientos de miles de webs como si fuera una mejora más.
Aviso por si te suena lejano, la misma semana cayó otro plugin con 800.000 instalaciones, y un par más al poco tiempo. Esto va a más, y conviene que sepas cómo defenderte.
Los 3 casos que la liaron parda
No es un caso aislado, es un patrón. En muy poco tiempo se descubrieron al menos tres ataques con el mismo guion, aunque el tipo de amenaza fue diferente.
Essential Plugin: el catálogo de plugins comprado en Flippa
Un comprador con perfil en SEO, criptomonedas y marketing de juego online adquirió en Flippa el catálogo completo de Essential Plugin (que antes se llamaba WP Online Support) por una cifra de seis dígitos a principios de 2025.
Eran más de treinta plugins con años de desarrollo legítimo y unas 400.000 instalaciones declaradas entre todos.
El 8 de agosto de 2025, en la versión 2.6.7 de los plugins, el nuevo dueño subió una actualización con un registro de cambios tan inocente que daba pereza leerlo, como tantos otros: «Check compatibility with WordPress version 6.8.2».
Detrás de ese texto venían 191 líneas extra de PHP con una puerta trasera de deserialización, que estuvo durmiente ocho meses.
El 5 de abril de 2026, el atacante activó la puerta trasera desde su servidor (analytics.essentialplugin.com) y las webs infectadas empezaron a servir spam SEO camuflado solo para Googlebot.
Los visitantes humanos veían la web normal, el propietario de la web veía el escritorio normal, pero Google veía una web llena de enlaces a chiringuitos de apuestas.
Patchstack y Anchor Hosting destaparon la liada y el 7 de abril WordPress.org cerró los 31 plugins de golpe.
Smart Slider 3 Pro: el servidor de actualizaciones comprometido
La misma semana el plugin Smart Slider 3 Pro (800.000 instalaciones) cayó por otra vía. Aquí no hubo compra del plugin, pero alguien consiguió acceso al servidor desde el que se distribuyen las actualizaciones premium y metió código malicioso en una versión normal.
El efecto para el usuario final fue el mismo, o sea, instalas una actualización oficial firmada por el autor de siempre y te llevas malware de regalo.
Widget Logic, Countdown Timer Ultimate y los que vendrán
El mismo patrón se ha visto en Widget Logic y Countdown Timer Ultimate, descubiertos en las semanas siguientes, y más que vendrán mientras no se le ponga algún tipo de freno.
El método es demasiado rentable como para que algún joputa no lo repita, porque no necesitas saber explotar una vulnerabilidad, ni buscarla, ni pelearte con un cortafuegos, compras la confianza ya forjada por otro y la usas contra los usuarios.
Cómo lo llaman a esta putada en inglés … y qué es exactamente
En la prensa especializada anglosajona lo llaman supply chain attack (ataque a la cadena de suministro), que no se tú, pero a mi no me dice nada, suena como a tomarse un te macha en una terraza de verano o poco más.
Y ya lo entiendo, que realmente no está mal traído, pues el término viene de la idea de que tu plugin no es solo el código que ves, es también el desarrollador, el repositorio, el servidor de actualizaciones y todos los eslabones intermedios.
Trata de definir que si uno de esos eslabones se corrompe, el código que tú instalas en tu web ya no es el que tú creías que era, aunque venga por el canal oficial.
La diferencia con un ataque tradicional es importante, porque en un ataque clásico los malos buscan un fallo en tu plugin para colarse. Aquí no necesitan buscar nada porque el plugin viene ya envenenado de origen.
La actualización que rompe tu web no es un exploit, es una versión oficial firmada por el autor original, distribuida por WordPress.org, instalada por tu sistema de actualizaciones automáticas como ha hecho mil veces antes. Por eso es tan difícil de parar.
Venga, acepto el nombre, pero a mi me pega más algo como cabronada, plugins envenenados o burra vieja, no se, ya me entiendes, soy más de andar por casa.
Por qué WordPress es el caldo de cultivo perfecto
Esto no pasa solo en WordPress, pero en WordPress pasa con especial facilidad por varias razones que conviene tener claras.
Los plugins se compran y se venden como cualquier otro activo digital
En marketplaces como Flippa puedes encontrar plugins en venta con sus 50.000, 100.000 o 400.000 instalaciones activas.
El comprador, sea quien sea y tenga las intenciones que tenga, hereda el acceso SVN al repositorio de WordPress.org y puede subir actualizaciones desde el minuto uno.
No hay un proceso de revisión del nuevo dueño, ni un aviso público en el escritorio del usuario diciendo «este plugin ha cambiado de manos, revisa antes de actualizar», nada.
Las actualizaciones automáticas funcionan en tu contra cuando esto pasa
Si tienes las activadas las actualizaciones automáticas para todos los plugins, que es la recomendación habitual razonable, recibes la versión envenenada sin enterarte.
De hecho muchos hosting incluso fuerzan las actualizaciones automáticas por defecto, por buena intención, pero aquí te das de bruces contra una putada que pervierte una buena idea original.
WordPress.org no firma el código
Otros ecosistemas como Debian, Microsoft Store o iOS exigen firma criptográfica para que el software que ejecutas pueda comprobarse contra una clave del autor original.
En WordPress eso no existe, si alguien hereda los permisos del autor puede subir lo que quiera sin que nadie compare nada contra nada.
No se tú, llámame loco, pero esto debería revisarse en las directrices del directorio de plugins, no es complicado de implementar, no es algo raro, y nos quitaría de mucho cabronazo malintencionado de estos.
El modelo de negocio del plugin gratuito empuja a vender
Mantener un plugin con miles de instalaciones es caro en tiempo, en soporte y en mantenimiento, y si no monetizas con versión premium ni con servicios llega un momento en el que abandonas o vendes.
Los compradores con intenciones limpias existen, la mayoría lo hacen por ese digno objetivo de ganar dinero lícitamente, pero también están los otros, que prefieren hacerse ricos a tu costa, y sin tu consentimiento.
¿He dicho ya que me cago en todos sus muertos?, por si acaso.
Cómo saber si tu web está infectada con plugins envenenados
Si tienes las actualizaciones automáticas activadas y alguno de los plugins comprometidos estaba instalado entre agosto de 2025 y abril de 2026, posiblemente tu sitio sirvió contenido manipulado durante un tiempo.
Estos son los indicadores que tienes que mirar ahora mismo.
Busca en wp-config.php
La puerta trasera de Essential Plugin se inyectaba en wp-config.php justo en la misma línea que el require_once ABSPATH . 'wp-settings.php';.
No estaba en una línea aparte, en la misma, para que sea fácil pasarlo por alto si revisas el archivo a ojo.
Abre tu wp-config.php por SFTP o desde el gestor de archivos del hosting y busca esa línea. Si ves cualquier cosa pegada a continuación o el archivo es notablemente más grande de lo normal (la inyección añade unos 6 KB), tienes un problema.
Busca el archivo wp-comments-posts.php
El payload activado creaba un archivo llamado wp-comments-posts.php en la raíz del WordPress. Si lo ves ahí no es tuyo, no es de una instalación normal, WordPress no tiene ningún archivo con ese nombre por defecto.
Revisa el listado de plugins cerrados
Entra en tu listado de plugins instalados, abre los detalles de cada uno y mira si aparece el aviso de «cerrado», o algo más claro en la página del plugin, pero tampoco para tirar cohetes.
Si lo ves lo desinstalas inmediatamente, no lo dejes ahí «por si lo reabren» o «por si arreglan algo». Los archivos siguen ejecutándose mientras estén ahí, aunque el plugin esté desactivado en WordPress.
Plugins de Essential Plugin
Si no recuerdas todos los plugins que tienes (o tenías), la lista completa de los 31 plugins de Essential Plugin afectados la mantienen actualizada en el análisis de Anchor Hosting.
Compara con tu lista de plugins instalados, incluso si están desactivados.
Mira los logs de Cloudflare o del hosting
Si tienes Cloudflare o cualquier CDN delante, revisa el tráfico saliente hacia analytics.essentialplugin.com en los últimos meses.
Si tu hosting te deja acceder a los logs de salida (no todos lo hacen), busca peticiones a ese dominio, es un indicador casi infalible.
Cómo te defiendes para el próximo ataque
Porque va a haber uno, no te quepa duda. La defensa contra este tipo de ataques no es una sola medida, son varias capas que tienen que trabajar juntas, te las cuento por orden de prioridad.
Detección de plugins cerrados
Cuando WordPress.org cierra un plugin (por vulnerabilidad grave, por código malicioso o por incumplir las normas del repositorio), no te avisa de manera clara.
Se marca el aviso en el listado de plugins, pero si no entras a esa pantalla a diario y miras los detalles de los plugins, te puedes pasar semanas con el plugin comprometido instalado sin enterarte. Esto es lo primero que tienes que automatizar.
Dos opciones para esto, estas:
- Wordfence detecta plugins cerrados y abandonados desde 2017. Es la opción más conocida, pero lo hace dentro de su escaneo de malware general, que la gente programa cada semana. Si el plugin se cierra el lunes y tu escaneo es el viernes, tienes cuatro días de margen.
- El plugin Vigilante tiene esta función, con un par de detalles que ayudan bastante. Por un lado, lanza una consulta diaria a la API de WordPress.org para cada plugin instalado (activado o no) y avisa el mismo día con un email crítico. Por otro, recuerda qué plugins estaban vivos antes, y si la API empieza a devolver 404 para un plugin que ayer respondía, lo trata como cierre con la misma gravedad que un cierre explícito (algunos cierres por motivos graves esconden la metadata del plugin entera, y si solo miras lo que devuelve la API te lo puedes perder). Además, los plugins cerrados aparecen en el escritorio como recomendación crítica con enlace directo, en la auditoría de seguridad como evento, y se siguen mostrando en cada email de resumen hasta que los desinstalas o los marcas como ignorados de forma explícita.
Cualquiera de las dos opciones es mejor que nada. Si ya tienes Wordfence lo dejas, si quieres detección más rápida y dedicada o no quieres meter Wordfence por su peso prueba con Vigilante.
Integridad de archivos
La inyección de la puerta trasera cambia archivos en el plugin y a veces en el wp-config.php. Un escáner de integridad de archivos que compare lo que hay en tu instalación con las sumas de comprobación oficiales de WordPress.org detecta cambios sospechosos.
Esto lo hacen Kadence Security, Vigilante y otros. Lo activas, lo programas cada día, y recibes un email cuando hay un archivo modificado que no esperabas. El truco está en no ignorar los avisos.
Cuando WordPress se actualiza, también te llegan avisos de archivos modificados (porque efectivamente se modifican), y la mayoría de nosotros nos acostumbramos a marcarlos como leídos sin mirar, y no, no lo hagas.
Si un email te avisa de cambios en plugins que no has actualizado, abre y mira.
Auditoría y registro de actividad
Tener un registro que te diga quién instala, activa, actualiza o desactiva plugins en tu web es un seguro barato, de hecho gratis.
Si alguien con acceso al admin de WordPress mete un plugin envenenado o activa uno que ya estaba desactivado queda registrado.
Lo incluyen casi todos los plugins de seguridad medianamente serios (como Vigilante), y sino también hay plugins específicos que son solo para esto.
Actualizaciones automáticas selectivas
Aquí va a ir contra lo que has leído mil veces, pero hay matices, porque sí, las actualizaciones automáticas son buena idea para plugins pequeños y/o bien mantenidos, especialmente si no son críticos para tu negocio.
Pero para plugins que tocan dinero o datos sensibles (WooCommerce, pasarelas de pago, formularios que recogen tarjetas, plugins de membresía, plugins de email transaccional) la actualización automática es una muy mala idea.
Te bajas la actualización a staging, miras el registro de cambios, esperas 48 horas a ver si alguien grita en los foros, y entonces actualizas a producción.
El caso Essential Plugin se distribuyó precisamente gracias a las actualizaciones automáticas. Quien las tenía desactivadas y revisaba los registros de cambios se salvó, aunque fuese por suerte o casualidad.
Protegiendo la comarca
Afortunadamente, el 5 de junio, coincidiendo con WordCamp Europe, se anunció que WordPress está poniendo en la nevera las actualizaciones de plugins durante 24 horas, para precisamente evitar cosas como lo que estamos hablando, para dar tiempo al equipo de plugins a revisar todas las actualizaciones, por supuesto ayudados de una IA especializada, a la que han llamado Gandalf, para que tenga de todo.
De momento son eso, 24 horas de espera, pero se irán reduciendo los tiempos a medida que se mejore el sistema.
Es una buenísima noticia, sí, pero no exime a nadie de responsabilidades, tampoco a ti.
Lo que no hace ningún plugin por ti
Ningún plugin de seguridad te salva de todo, hay cosas que tienes que hacer tú, con tu equipo o contratando a alguien que se ocupe por ti, y no hay automatización que las sustituya.
Revisar el registro de cambios antes de actualizar plugins críticos es una de ellas. Un changelog que dice «Check compatibility with WordPress version 6.8.2» y la actualización pesa 6 KB más, debería levantarte la ceja. No siempre se nota tan claro, pero a veces sí, y conviene mirar.
Suscribirte a feeds de bases de datos de vulnerabilidades es otra. Patchstack, WPScan y Wordfence Intelligence publican avisos a diario. No necesitas leerlos todos, pero suscribirte a sus newsletters semanales te da una visión general del panorama sin esfuerzo.
Seguir el foro de soporte de los plugins que usas en webs importantes también ayuda. Si un plugin con muchas instalaciones se ha vuelto raro, los foros se llenan de quejas a las pocas horas, y tener cinco o seis plugins críticos en favoritos del foro de WordPress.org no cuesta nada.
Desconfiar de cualquier plugin que cambie de dueño y desinstalarlo si puedes vivir sin él es la medida más radical, pero también la más segura. Si te enteras de que un plugin que usas ha sido vendido te tomas un par de horas para evaluar alternativas y mantenerte preparado por si la cosa va mal. No siempre va mal, pero cuando va ya no hay tiempo.
Y mantener backups, sí, otra vez. Copias de seguridad de verdad, fuera de tu servidor, probados, recientes y restaurables en menos de una hora.
Si te ha pasado lo de Essential Plugin y no quieres pelearte con la limpieza, lo más rápido suele ser restaurar a antes de la infección y aplicar lo aprendido para no caer otra vez.
Lista de tareas para ya
Si has llegado hasta aquí, dedica un rato hoy mismo a hacer esto. No te lleva más de una hora, dependiendo del tamaño de tu web.
- Revisa el listado de plugins instalados (incluso los desactivados) y comprueba si aparece alguno con el aviso de «cerrado». Si lo hay, desinstálalo.
- Cruza tu listado contra el de lo 31 plugins de Essential Plugin del enlace de Anchor Hosting que te he puesto más arriba. Si te coincide alguno, asume que tu web estuvo comprometida y empieza la limpieza desde wp-config.php.
- Abre tu wp-config.php por SFTP y busca código extraño junto a la línea de
require_once ABSPATH . 'wp-settings.php';. Si lo ves, restaura el archivo desde un backup limpio. - Comprueba si existe un archivo
wp-comments-posts.phpen la raíz de tu WordPress. Si está lo borras sin piedad. - Instala y activa un plugin de seguridad que tenga detector de plugins cerrados. Wordfence o Vigilante, el que prefieras.
- Activa el escáner de integridad de archivos con email diario del plugin de seguridad, y si no tiene esa herramienta cambia de plugin de seguridad.
- Activa también la auditoría de registro de actividad para saber quién toca qué.
- Desactiva las actualizaciones automáticas en los plugins que tocan dinero o datos sensibles. Planifica un proceso manual de revisión semanal.
- Suscríbete al boletín de Patchstack o Wordfence Intelligence. Cinco minutos a la semana leyendo te ahorra muchos disgustos.
- Si gestionas webs de clientes, comprueba estos mismos puntos en todas las que mantienes. Si tienes diez webs, una hora por web es un día de trabajo bien invertido.
Lo del software libre que confías a desconocidos por defecto va a seguir pasando.
Mientras WordPress.org no obligue a firmar el código y a auditar las transferencias de propiedad (que no parece que vaya a pasar pronto), la mejor defensa eres tú.
Aplícate al cuento, sigue estos consejos que te he dado, no pasa nada por ser un poco paranoico con los plugins críticos, dormirás más tranquilo, es mucho peor ser confiado con las cosas del comer.
¿Te gustó este artículo? ¡Ni te imaginas lo que te estás perdiendo en YouTube!
