En abril de 2026, WordPress.org cerró 31 plugins de WPFactory tras descubrir que uno de ellos, Essential Plugin (v2.6.7), contenía un backdoor activo. El código malicioso estuvo dormante ocho meses antes de activarse el 5 de abril, afectando miles de sitios. Los plugins están bajo revisión y temporalmente no disponibles para nuevas instalaciones.
En 30 segundos
- Un comprador anónimo («Kris») adquirió WPFactory en Flippa en agosto de 2025 por seis cifras y luego inyectó un backdoor en la versión 2.6.7 de Essential Plugin.
- El código estuvo 8 meses sin activarse; el 5 de abril de 2026 comenzó a inyectar spam SEO invisible y a comprometer archivos críticos como wp-config.php.
- WordPress.org suspendió los 31 plugins de WPFactory el 7 de abril de 2026, dos días después de la activación.
- La actualización 2.6.9.1 desactivó la función maliciosa pero no eliminó el código inyectado en sitios ya comprometidos.
- Si tenías cualquiera de estos plugins instalados, tu sitio puede estar comprometido aunque hayas actualizado.
El ataque al Essential Plugin: qué pasó en abril de 2026
Un ataque de cadena de suministro es cuando alguien compromete no tu sitio directamente, sino el software que instalás en él. Ponele que confiás en un plugin con 50.000 instalaciones activas, lo actualizás como siempre, y justo en esa actualización viene el código malicioso. Eso es exactamente lo que ocurrió con WPFactory y sus plugins WordPress cerrados backdoor incluido.
La historia arranca en agosto de 2025. Un comprador que se identificó como «Kris» adquirió WPFactory, una empresa con un portafolio de 31 plugins de WordPress, a través de la plataforma de compraventa Flippa por un monto de seis cifras. WPFactory era un vendedor legítimo con años de trayectoria, plugins bien valorados y una base real de usuarios.
Lo que siguió fue paciente y calculado.
El nuevo dueño publicó la versión 2.6.7 de Essential Plugin con 191 líneas de código adicional. Nada explotó de inmediato. El backdoor se quedó dormido desde agosto hasta el 5 de abril de 2026, cuando según TechRepublic se activó masivamente, comenzando a modificar archivos en miles de instalaciones. WordPress.org respondió dos días después, el 7 de abril, cerrando los 31 plugins del portafolio WPFactory mientras duraba la investigación.
¿Por qué esperar ocho meses? Probablemente para evitar que las herramientas de seguridad correlacionaran la instalación del plugin con el comportamiento malicioso. Un período de latencia largo hace que la infección parezca preexistente, no reciente.
Lista de los 31 plugins de WordPress cerrados
Todos los plugins del portafolio WPFactory quedaron suspendidos en WordPress.org. Entre los más instalados estaban estos:
| Plugin | Instalaciones activas (aprox.) | Función |
|---|---|---|
| Countdown Timer Ultimate | +40.000 | Temporizadores de cuenta regresiva |
| Popup Anything on Click | +30.000 | Popups y overlays |
| WP Testimonial with Widget | +20.000 | Testimonios y reseñas |
| WP Team Showcase | +15.000 | Presentación de equipos |
| Hero Banner Ultimate | +12.000 | Banners y headers visuales |
| Post Grid and Filter Ultimate | +25.000 | Grillas y filtros de contenido |
| Essential Plugin | +50.000 | Utilidades generales (el comprometido) |
El resto del portafolio incluye plugins de sliders, galerías, formularios y widgets varios. Si alguna vez instalaste un plugin de WPFactory (no solo Essential Plugin), revisá tu instalación. La suspensión afecta a todos.
Cómo funcionaba el backdoor técnicamente
Las 191 líneas inyectadas hacían varias cosas a la vez, y ninguna era inocente.
Primero, el código usaba PHP deserialization para ejecutar instrucciones remotas. Eso solo ya es una bandera roja enorme: la deserialización no sanitizada es uno de los vectores de ataque más explotados en PHP porque permite ejecutar código arbitrario si el atacante controla el input.
Segundo, la comunicación con el servidor de comando y control no usaba una IP convencional. Según Cryptika, el backdoor se comunicaba a través de un smart contract de Ethereum, lo que hace que bloquear el C2 por IP o dominio sea prácticamente inútil (un contrato en una blockchain pública no se puede «tumbar»).
Tercero, inyectaba spam SEO en el contenido del sitio: links y texto invisible para los usuarios humanos, pero perfectamente legible por Googlebot. El objetivo era beneficiar a otros sitios con linkbuilding a costa del domain authority de los sitios infectados. Mientras tanto, el dueño del sitio no veía nada raro.
Cuarto, modificaba archivos críticos: wp-config.php y wp-admin.php. Y acá viene la parte que no todos entendieron bien con la actualización de emergencia: la versión 2.6.9.1 desactivó la función maliciosa en el plugin, pero no limpió el código que ya había inyectado en esos archivos. O sea, actualizaste, el plugin está «limpio», pero tu wp-config.php sigue teniendo el código del atacante adentro. El sitio sigue comprometido (sí, en serio).
También dejaba abierto un endpoint REST API sin autenticación. Cualquier persona que supiera de su existencia podía interactuar con el sitio sin credenciales.
¿Tenés tu sitio comprometido? Cómo detectar la infección
Si instalaste cualquier plugin de WPFactory después de agosto de 2025, asume que estás comprometido hasta que puedas verificar lo contrario. Acá van las cosas concretas que revisar:
- wp-config.php: Compará tu archivo con wp-config-sample.php. Cualquier código PHP que no sea configuración de base de datos, claves de autenticación o constantes de WordPress es sospechoso. Buscá funciones como eval(), base64_decode(), preg_replace() con modificador /e, o includes a URLs externas.
- wp-admin.php: No debería tener más de 10-15 líneas. Si tiene código PHP adicional, está comprometido.
- Uploads con PHP: Buscá archivos .php dentro de /wp-content/uploads/. No deberían existir. Si existen, son backdoors o webshells.
- Scanner externo: Usá Sucuri SiteCheck o el scanner de Wordfence (si lo tenés instalado y no está comprometido). Priorizá Sucuri porque escanea desde afuera y no depende de plugins del propio sitio.
- Google Search Console: Revisá si aparecieron URLs raras indexadas, con spam o que no reconocés. También fijate en Coverage > Discovered – currently not indexed por si hay páginas que Google encontró pero vos no creaste.
- Logs de acceso: Buscá requests a REST API endpoints que no reconocés, especialmente desde IPs repetidas.
Los signos más visibles: redirects a sitios de spam cuando accedés al sitio desde Google (pero no directamente), links extraños en el footer que desaparecen si inspeccionás desde el admin, o Google marcando el sitio como «engañoso» en Search Console.
Pasos para limpiar un WordPress infectado por este backdoor
Esto no es «eliminá el plugin y listo». Si el backdoor ya se activó en tu sitio, hay archivos modificados que hay que limpiar a mano.
Paso 1: Activá modo mantenimiento y tomá una copia de seguridad
Antes de tocar nada, creá una copia del estado actual (sí, incluso del sitio infectado). La vas a necesitar si algo sale mal durante la limpieza. Luego activá modo mantenimiento para que nadie más interactúe con el sitio mientras trabajás.
Paso 2: Cambiá los salts de wp-config.php e invalidá sesiones activas
WordPress.org tiene un generador de salts en línea. Reemplazá las claves AUTH_KEY, SECURE_AUTH_KEY, y el resto. Esto cierra todas las sesiones activas, incluyendo las del atacante si tenía una sesión abierta.
Paso 3: Reinstalá wp-admin y wp-includes desde el repositorio oficial
Bajá la misma versión de WordPress que tenés instalada, descomprimila, y reemplazá las carpetas wp-admin y wp-includes completas vía FTP o SFTP. No toques wp-content todavía.
Paso 4: Eliminá los plugins comprometidos y reinstalá versiones limpias
Eliminá la carpeta completa de cada plugin WPFactory desde /wp-content/plugins/. No actualices, no desactivés y borrés: eliminá la carpeta. Si el plugin estaba en WordPress.org antes de la suspensión y lo necesitás, esperá a que lo rehabiliten (si es que lo hacen). Buscá alternativas mientras tanto.
Paso 5: Auditá wp-config.php y wp-admin.php manualmente
Abrí ambos archivos en un editor de texto y revisá línea a línea. wp-config.php debería tener solo configuración. wp-admin.php debería ser el archivo estándar de WordPress. Cualquier código adicional, fuera.
Paso 6: Buscá y eliminá PHP en uploads
Desde SSH o FTP, buscá todos los archivos .php en /wp-content/uploads/ y elimináslos. También revisá si hay archivos .htaccess en subcarpetas de uploads (no deberían estar ahí).
Paso 7: Cambiá todas las contraseñas
Todas: la de WordPress (especialmente admins), la de la base de datos, la de FTP/SFTP, y la del panel de hosting. Si alguien tuvo acceso vía el backdoor, puede haber exfiltrado credenciales.
Paso 8: Verificá con scanner después de la limpieza
Usá Sucuri SiteCheck o Wordfence para confirmar que la limpieza fue completa. Si el scanner sigue encontrando problemas, probablemente haya un archivo comprometido que no detectaste.
Cómo protegerse de futuros ataques de cadena de suministro en WordPress
Este caso tiene una lección central: el plugin venía de WordPress.org, tenía historia legítima, buenas valoraciones, y aun así estaba comprometido. El origen no garantiza nada si el dueño del plugin cambió.
Las medidas concretas:
- Desinstalá plugins que no usás. Cada plugin inactivo es superficie de ataque sin valor. Si no lo usás, sacalo.
- Monitoreá cambios de autoría en WordPress.org. Algunos servicios de monitoreo de plugins alertan cuando un plugin cambia de mantenedor. Vale la pena configurarlo para los plugins críticos.
- No compres plugins de Flippa ni mercados secundarios. Los plugins legítimos se compran en WordPress.org o directamente del desarrollador verificado. Flippa es para comprar negocios web, no para confiar ciegamente en el código que viene con ellos.
- Implementá un WAF. Un Web Application Firewall detecta y bloquea patrones de comportamiento sospechoso, incluyendo intentos de acceso a REST API endpoints no estándar.
- Monitoreá cambios en archivos críticos. Wordfence tiene alertas de integridad de archivos. Si alguien modifica wp-config.php, recibís una notificación.
- Backups regulares y verificados. Tener backups es el mínimo. Verificar que se pueden restaurar es lo que importa. Si usás un hosting como donweb.com, revisá que los backups automáticos del servidor estén configurados y probá una restauración de prueba.
- Nunca plugins nulled. Si un plugin premium «se consigue gratis» en algún sitio, el precio real lo pagás con tu sitio comprometido. Sin excepciones.
El ecosistema WordPress en 2026: los números que hay que conocer
Este incidente no es un caso aislado. El ecosistema de plugins de WordPress arrastra un problema estructural que viene escalando.
Según datos de abril de 2026, durante 2025 se registraron 11.334 nuevas vulnerabilidades en el ecosistema WordPress, un aumento del 42% respecto a 2024. El 91% de esas vulnerabilidades estaban en plugins. Las vulnerabilidades clasificadas como «altamente explotables» crecieron un 113%. Eso es aproximadamente una vulnerabilidad nueva cada 3-4 horas, todos los días del año.
Más de 17.000 sitios fueron hackeados a través de vulnerabilidades en plugins premium, y el caso WPFactory comprometió directamente miles de instalaciones con su activación del 5 de abril.
¿Qué significa eso para un administrador de WordPress promedio? Que mantener un sitio seguro hoy requiere más que actualizar plugins. Requiere auditar qué plugins tenés, verificar que los desarrolladores siguen siendo quienes decís que son, y tener procesos de detección activos.
Qué está confirmado y qué todavía no está claro
| Estado | Detalle |
|---|---|
| Confirmado | WordPress.org cerró los 31 plugins de WPFactory el 7 de abril de 2026 |
| Confirmado | Essential Plugin v2.6.7 contenía el backdoor; 191 líneas de código inyectado |
| Confirmado | El backdoor se activó el 5 de abril de 2026 tras 8 meses dormante |
| Confirmado | La versión 2.6.9.1 desactivó la función pero no limpió sitios ya comprometidos |
| Confirmado | El C2 usaba un smart contract de Ethereum como mecanismo de comunicación |
| Pendiente | Identidad real del comprador «Kris» y si hay más compradores involucrados |
| Pendiente | Cuántos sitios exactamente quedaron comprometidos (miles, sin cifra oficial) |
| Pendiente | Si WordPress.org rehabilitará alguno de los 31 plugins una vez auditados |
| Pendiente | Si hay otros portafolios de plugins comprados en Flippa con el mismo patrón |
Errores comunes al manejar este tipo de incidente
Error 1: Actualizar el plugin y asumir que el problema está resuelto. La actualización a 2.6.9.1 desactivó el backdoor en el plugin, pero si ya se activó en tu sitio, el código inyectado en wp-config.php y wp-admin.php sigue ahí. Actualizar no limpia el daño ya hecho. Hay que revisar manualmente los archivos comprometidos.
Error 2: Eliminar el plugin y restaurar un backup «reciente» sin verificar la fecha. Si el backdoor se activó el 5 de abril y tu backup es del 3 de abril, está bien. Si es del 10 de abril, el backup ya tiene la infección. Verificá siempre qué fecha tiene el backup antes de restaurar.
Error 3: Cambiar solo la contraseña de WordPress. Si el backdoor modificó wp-config.php, el atacante tiene las credenciales de la base de datos. Si comprometió FTP, tiene acceso al sistema de archivos. Hay que cambiar todas las credenciales, no solo las de WordPress.
Mirá nuestro análisis de WPFactory WordPress plugins closed after possible backdoor i para profundizar en esto.
Preguntas Frecuentes
¿Cuál fue el ataque al Essential Plugin de WordPress?
Un comprador adquirió WPFactory en agosto de 2025 e inyectó un backdoor en la versión 2.6.7 de Essential Plugin. El código estuvo dormante ocho meses y se activó el 5 de abril de 2026, comprometiendo miles de sitios al modificar archivos críticos como wp-config.php e inyectar spam SEO invisible. WordPress.org cerró los 31 plugins del portafolio WPFactory el 7 de abril.
¿Cómo verifico si mi sitio WordPress tiene plugins comprometidos?
Revisá manualmente wp-config.php comparándolo con wp-config-sample.php para detectar código extraño, buscá archivos PHP en /wp-content/uploads/, y usá el scanner de Sucuri SiteCheck. También revisá Google Search Console para detectar URLs de spam indexadas que no reconocés.
¿Qué debo hacer si tenía los plugins de WPFactory instalados?
Asume que estás comprometido y actuá en consecuencia: eliminá la carpeta completa del plugin (no solo desactivarlo), auditá manualmente wp-config.php y wp-admin.php, cambiá todos los salts de WordPress y todas las contraseñas del sistema, y escaneá con Sucuri o Wordfence para verificar que la limpieza quedó completa.
¿Cómo limpiar un WordPress infectado con backdoor en wp-config.php?
Abrí wp-config.php en un editor de texto y comparalo con el archivo de muestra de WordPress. Eliminá cualquier función PHP que no sea configuración estándar (eval, base64_decode, includes a URLs externas). Luego regenerá los salts de autenticación, cambiá la contraseña de base de datos, y verificá con un scanner. Si no estás seguro de qué eliminar, restaurá desde un backup anterior al 5 de abril de 2026.
¿Cómo prevenir futuros ataques de cadena de suministro en WordPress?
Las medidas más efectivas son: no instalar plugins de fuentes secundarias como Flippa, desinstalar plugins que no usás activamente, monitorear cambios de autoría en plugins de WordPress.org, implementar un WAF, y configurar alertas de integridad de archivos en Wordfence. Un backup verificado y reciente es tu red de seguridad cuando todo lo demás falla.
Conclusión
El caso WPFactory cambia la forma en que hay que pensar la seguridad de plugins en WordPress. Antes, el criterio era: ¿está en WordPress.org? ¿tiene buenas valoraciones? ¿se actualiza seguido? Listo, confiable. Ahora ese criterio es insuficiente, porque el problema no estaba en el plugin original sino en quién lo compró y qué hizo después.
Los ataques de cadena de suministro son más sofisticados que una vulnerabilidad común porque explotan la confianza que ya construiste. No hay parche para eso. La respuesta tiene que ser más diversa: menos plugins, monitoreo activo de cambios, backups verificados, y más escepticismo ante actualizaciones que llegan de portafolios que cambiaron de dueño.
Si tenías cualquier plugin de WPFactory, revisá tu sitio hoy. No mañana.
Fuentes
- TechCrunch – Backdoors en docenas de plugins de WordPress usados en miles de sitios
- MySites.guru – Essential Plugin WordPress backdoor: análisis del incidente
- Cryptika – Backdoor en plugins confiables de WordPress durante 8 meses
- LPB Digital – Plugins WordPress infectados en abril de 2026
- WP Poland – Guía de auditoría para ataque de cadena de suministro en WordPress 2026