WordPress bajo ataque: detecta backdoors en mu-plugins

Los atacantes están usando los mu-plugins de WordPress para esconder backdoors que sobreviven a limpiezas, instalan cuentas admin falsas e inyectan spam invisible que destruye el posicionamiento orgánico. El vector es técnicamente elegante y, por años, pasó completamente desapercibido.

WordPress es un sistema de gestión de contenidos de código abierto creado por Matt Mullenweg y Mike Little en 2003, y actualmente desarrollado por la WordPress Foundation. Permite crear, editar y publicar contenido en sitios web, blogs y tiendas online sin necesidad de programación avanzada.

¿Qué son los mu-plugins en WordPress y por qué son un objetivo privilegiado?

Un mu-plugin (must-use plugin) es un archivo PHP ubicado en wp-content/mu-plugins/ que WordPress carga automáticamente en cada request, antes que cualquier plugin regular, sin importar si está «activado» o no. No requiere activación manual. No aparece en la pantalla de Plugins del panel de administración (a menos que vayas específicamente a la pestaña «Must-Use» que la mayoría de los administradores nunca visita). No puede desactivarse desde wp-admin.

El propósito original es legítimo: los desarrolladores los usan para funcionalidades críticas que no deben desactivarse accidentalmente. Pero fijate qué panorama le presentan a un atacante: código que corre siempre, que el administrador no ve en la lista de plugins, que ningún plugin de seguridad estándar escanea por defecto, y que persiste incluso si el dueño del sitio «desactiva todos los plugins» para diagnosticar un problema.

La diferencia técnica con un plugin regular no es menor. Un plugin en wp-content/plugins/ tiene que estar en la tabla wp_options bajo active_plugins para ejecutarse. Un mu-plugin no necesita ninguna entrada en la base de datos. Existe en el filesystem y eso es suficiente. Para alguien que quiere persistencia con bajo perfil, es el lugar ideal.

Cómo funciona el ataque: dropper, loader y ejecución con eval()

El ciclo completo de un ataque via mu-plugins sigue un patrón bastante consistente entre las variantes documentadas por el equipo de Sucuri:

Primero, el acceso inicial. Puede venir de una credencial comprometida, un plugin con vulnerabilidad conocida, o (como veremos en los casos de 2026) directamente desde un plugin que el atacante metió en el repositorio oficial. Una vez dentro, el atacante deposita un archivo PHP en wp-content/mu-plugins/. El nombre suele ser genérico: class-update.php, maintenance.php, wp-utils.php. Nada que llame la atención.

El archivo en sí no contiene el payload. Contiene un loader. El código ofuscado (ROT13, codificación Base64, o string encoding personalizado) descarga el payload real desde una URL externa, que puede ser un repositorio de GitHub, una cuenta de Pastebin, o directamente desde un servidor C2. El payload se almacena en la base de datos, en wp_options bajo una clave con nombre inocente, y se ejecuta con eval() en cada request. Tema relacionado: estructura y funcionamiento de los plugins.

Una técnica especialmente problemática que documentó The Hacker News: el malware detecta el user-agent del visitante. Si viene Googlebot, sirve contenido spam con links de afiliados y palabras clave farmacéuticas o de juego online. Si viene un humano real, muestra el sitio normal. El administrador no ve nada raro. Google indexa el spam. El daño SEO ocurre en silencio durante semanas.

Síntomas reales: cómo detectar un WordPress backdoor mu-plugins antes de que sea tarde

Algunos síntomas son gritones. Otros son sutiles hasta que revisás los logs.

• Redirecciones inesperadas: usuarios en mobile que llegan a páginas de farmacia online o casinos. En desktop no pasa nada. Es la variante más común de la detección por user-agent.
• Cuentas administrador que no reconocés: revisá Usuarios → Administradores en wp-admin. Una cuenta extra con email raro o creada en fecha que no coincide con ninguna acción tuya es señal de alarma.
• Cambios en títulos o meta descriptions: si RankMath o Yoast muestran keywords que vos no pusiste (viagra, casino, préstamos), el malware está inyectando contenido en los campos SEO.
• Advertencias en Google Search Console: el apartado «Seguridad y Acciones Manuales» te va a mostrar si Google ya detectó el problema. Para entonces ya llevas semanas de daño acumulado.
• Tráfico saliente anómalo: logs del servidor con requests a dominios que no reconocés, especialmente si son frecuentes y regulares (comunicación C2).
• Archivos PHP en wp-content/uploads/: no debería haber archivos PHP ahí. Si los hay, son malware. Siempre.

Para revisar directamente: conectate por FTP o SSH y listá el contenido de wp-content/mu-plugins/. Si encontrás archivos que no pusiste vos, fecha de modificación reciente o nombres genéricos que no reconocés, procedé con desconfianza total.

SEO poisoning: cómo el malware destruye años de posicionamiento

El SEO poisoning es el daño más difícil de cuantificar y el más lento de reparar. La mecánica es simple: el backdoor inyecta bloques de texto HTML invisible para los visitantes humanos (color blanco sobre fondo blanco, tamaño de fuente 0px, o hidden con CSS) pero perfectamente legible para Googlebot. Ese contenido spam lleva links hacia dominios de pharma, juego, o piratería.

¿Qué pasa después? Google empieza a asociar tu dominio con esas keywords. El algoritmo registra que desde tu sitio salen links hacia dominios problemáticos. En algunos casos activa una acción manual («el sitio contiene contenido generado por hackers»). Tu tráfico orgánico empieza a caer, tus posiciones en keywords legítimas bajan, y el dominio puede entrar en listas negras de Google Safe Browsing.

El tiempo de recuperación, una vez limpiado el sitio, solicitada la revisión en GSC, y con la acción manual levantada, es de 4 a 12 semanas en promedio. Si el daño fue extenso o el dominio terminó en lista negra, puede extenderse meses. Para un sitio que monetiza con tráfico orgánico, eso es dinero concreto que no vuelve.

Persistencia técnica: por qué borrar un archivo no alcanza

Esta es la parte donde muchos administradores se equivocan. Encuentran el archivo malicioso en mu-plugins, lo borran, dan el problema por resuelto y tres días después el backdoor volvió. Pasa siempre.

El malware moderno implementa múltiples capas de persistencia:

• Backup en base de datos: el payload está serializado en wp_options bajo claves como wp_session_tokens_config o nombres que imitan opciones legítimas. Cuando el archivo mu-plugin se borra, el loader está en la BD y se reinstala.
• Copias en múltiples directorios: además de mu-plugins, hay copias en uploads, themes, o dentro de archivos de plugins legítimos con nombres de función similares.
• Comunicación C2 via blockchain: la variante EtherHiding, documentada por investigadores de seguridad, usa contratos de Ethereum para recibir instrucciones del atacante. Bloqueá el dominio C2 y el malware simplemente lee las instrucciones desde la blockchain pública. No podés bloquear Ethereum.
• Shell via parámetro GET: algunos backdoors aceptan comandos PHP via parámetro GET con una clave hardcodeada. Aunque borres todos los archivos, si tenés la key, podés volver a infectar el sitio en segundos.
• Cuentas admin reinstaladas: si no eliminás la cuenta falsa de administrador, el atacante puede volver a conectarse y re-desplegar el malware manualmente.

El mensaje es claro: la limpieza tiene que ser total o no sirve.

Casos documentados en 2025-2026: ataques masivos y miles de sitios afectados

En abril de 2026, TechCrunch publicó la investigación sobre un actor que compró más de 30 plugins legítimos del repositorio oficial de WordPress. Los plugins tenían base de usuarios real, buenas reviews, y habían funcionado correctamente durante años. El comprador insertó backdoors en actualizaciones que parecían normales. Los backdoors permanecieron inactivos desde agosto de 2025 hasta principios de 2026 (ocho meses sin activarse), lo que les permitió pasar todos los escaneos de seguridad automáticos. Cuando se activaron, miles de sitios ya tenían el malware instalado sin saberlo.

Ese mismo año, investigadores documentaron la variante EtherHiding: malware que usa contratos de Ethereum para recibir URLs de payload dinámicamente. Cada vez que un investigador bloqueaba la URL del C2, el atacante actualizaba el contrato con una URL nueva. El malware combinaba minería de criptomonedas en background con SEO poisoning y robo de cookies de sesión. Te puede servir nuestra cobertura de plugins de seguridad confiables y verificados.

Entre las vulnerabilidades explotadas como vector de entrada inicial en estos ataques, tres concentraron la mayoría de los casos: CVE-2024-27956 (inyección SQL en WP Automatic), CVE-2024-25600 (RCE en Bricks Builder, CVSS 10.0) y CVE-2024-8353 (GiveWP, acceso no autenticado). Los tres tenían parches disponibles. Los sitios comprometidos simplemente no los habían aplicado.

Limpieza completa: paso a paso para eliminar un backdoor de mu-plugins

Antes de arrancar: tomá un backup completo del estado actual, incluso comprometido. Lo vas a necesitar para comparar archivos.

1. Escaneo inicial

Corré Wordfence (escaneo completo) o Sucuri Scanner. Anotá cada archivo que marquen como sospechoso o modificado. No borres nada todavía.

2. Eliminación del mu-plugin malicioso

Via FTP/SSH, revisá cada archivo en wp-content/mu-plugins/. Cualquier archivo que no reconozcas o que el scanner marcó, eliminalo. Si hay subdirectorios dentro de mu-plugins con archivos PHP (los loaders a veces se estructuran así), eliminá el directorio completo.

3. Limpieza de base de datos

Conectate a la BD via phpMyAdmin o Adminer. Revisá wp_options buscando valores que contengan eval(, base64_decode(, str_rot13(, o URLs externas en campos donde no debería haberlas. Buscá también la tabla wp_session_tokens_config: si existe y no la creaste vos, es del malware.

4. Eliminación de cuentas admin falsas

En wp-admin, Usuarios → Administradores. Cualquier cuenta que no reconozcas: eliminala. Antes de borrar, fijate el email asociado (puede darte información sobre el atacante) y asigná sus posts a tu cuenta si corresponde. Relacionado: automatización segura sin usar eval().

5. Cambio de credenciales completo

Cambiá: contraseña de todos los usuarios admin, App Passwords de WordPress, contraseña de la base de datos (y actualizá wp-config.php), contraseña FTP/SSH, credenciales de hosting. Si usás tokens de API (GSC, WooCommerce, etc.), regeneralos todos.

6. Auditoría de archivos del core

Descargá una copia limpia de la misma versión de WordPress que tenés e instalada. Compará archivo por archivo los directorios wp-admin/ y wp-includes/. Cualquier diferencia es sospechosa. Wordfence tiene una función de «reparar archivos de WordPress» que hace esto automáticamente.

7. Revisión de wp-content/uploads/

Buscá archivos PHP en el directorio uploads. No debería haber ninguno. Si encontrás, borralos. Para prevenir futuros: agregá una regla en .htaccess dentro de uploads que bloquee la ejecución de PHP.

Prevención: hardening para no volver a pasar por esto

La prevención no es un plugin. Es un conjunto de hábitos.

Lo fundamental: mantené WordPress, plugins y temas actualizados. El 70% de las infecciones documentadas en 2025-2026 explotaron vulnerabilidades con parche disponible que simplemente no se había aplicado. Activá las actualizaciones automáticas para versiones menores del core.

Sobre plugins: instalá solo desde el repositorio oficial de wordpress.org y con historial de actualizaciones activo. Plugins sin actualización en más de dos años son riesgo. El caso de los 30 plugins comprados en 2026 demuestra que incluso plugins legítimos pueden convertirse en vector, lo que hace que el monitoreo post-instalación sea tan importante como la selección inicial.

Medidas de hardening concretas:

• Activá 2FA para todos los usuarios con rol editor o superior. Wordfence y otros plugins lo implementan en minutos.
• Limitá los intentos de login (Limit Login Attempts Reloaded o similar).
• Agregá en .htaccess la regla que bloquea ejecución de PHP en uploads: php_flag engine off.
• Auditá la lista de usuarios administradores cada semana. Es un chequeo de 30 segundos que puede detectar un compromiso antes de que cause daño.
• Configurá alertas de Wordfence para que te notifique por email ante cualquier cambio en archivos del core o creación de cuentas admin.
• Backups diarios externos al servidor. Si tu proveedor de hosting los guarda en el mismo servidor, no te salvan de un compromiso total. Si usás donweb.com como hosting, revisá que los backups externos estén activos en el panel.

Un WAF (Web Application Firewall) agrega una capa que puede bloquear exploits antes de que lleguen a WordPress. Wordfence tiene uno integrado. Para sitios de mayor tráfico o con datos sensibles, vale considerar una solución a nivel de servidor. Para más detalles técnicos, mirá diferencias entre mu-plugins y plugins regulares.

Errores comunes al limpiar un WordPress comprometido

Error 1: Creer que reinstalar WordPress limpia todo. WordPress solo reinstala el core. Los plugins, temas, mu-plugins, uploads, y la base de datos quedan intactos. Si el malware está en cualquiera de esas ubicaciones (y generalmente está), la reinstalación no hizo nada útil.

Error 2: Borrar solo el archivo visible del malware. Ya lo dijimos: el malware tiene copias de respaldo. Si solo borrás el archivo que te señaló el scanner, el backdoor se reinstala en horas. La limpieza tiene que cubrir filesystem, base de datos, y credenciales al mismo tiempo.

Error 3: No investigar el vector de entrada inicial. Si limpiás el sitio pero no sabés cómo entraron, van a volver a entrar. Revisá logs de acceso del servidor buscando requests sospechosos antes de la fecha de infección. Identificá qué plugin o credencial fue el punto de entrada y atendé ese problema específico.

Justo esto es lo que pasó en WordPress site compromised via mu-plugins backdoor: SEO pois que documentamos.

Esto se conecta con WordPress site compromised via mu-plugins backdoor: SEO pois, donde cubrimos el tema en detalle.

Preguntas Frecuentes

¿Qué son los mu-plugins de WordPress?

Los mu-plugins (must-use plugins) son archivos PHP ubicados en wp-content/mu-plugins/ que WordPress carga automáticamente en cada request sin necesidad de activación manual. No aparecen en la lista de plugins del panel de administración y no pueden desactivarse desde wp-admin. Su propósito original es alojar funcionalidades críticas que no deben desactivarse accidentalmente.

¿Cómo puedo detectar si mi sitio WordPress está comprometido via mu-plugins?

Revisá el contenido de wp-content/mu-plugins/ via FTP o SSH y verificá que cada archivo lo colocaste vos o tu equipo. Revisá también Google Search Console en Seguridad y Acciones Manuales, la lista de usuarios administradores en wp-admin, y corré un escaneo completo con Wordfence o Sucuri Scanner. Redirecciones inesperadas en mobile o cambios en títulos SEO que no hiciste son señales inmediatas.

¿Por qué los atacantes prefieren mu-plugins para esconder malware?

Porque los mu-plugins se cargan antes que cualquier plugin de seguridad (incluyendo Wordfence), no aparecen en la pantalla de administración de plugins, y no requieren ninguna entrada en la base de datos para ejecutarse. Eso les da máxima invisibilidad y mínima superficie de detección. Un administrador puede revisar «todos los plugins activos» y nunca ver el malware.

¿Cuáles son los síntomas de un WordPress con backdoor activo?

Los síntomas más frecuentes son: redirecciones a sitios de spam (especialmente en mobile), cuentas administrador desconocidas en la lista de usuarios, advertencias de Google Safe Browsing, caída brusca del tráfico orgánico sin causa aparente, y archivos PHP inesperados en wp-content/uploads/. Los backdoors con detección de Googlebot pueden no mostrar síntomas visibles para el administrador hasta que Google emite una acción manual.

¿Cómo puedo limpiar un WordPress hackeado con mu-plugin malicioso?

La limpieza requiere siete pasos en secuencia: escaneo con Wordfence/Sucuri para mapear todo el malware, eliminación del archivo mu-plugin malicioso, limpieza de la base de datos (especialmente wp_options), eliminación de cuentas admin falsas, cambio completo de credenciales (WP, BD, FTP, hosting), comparación del core con una instalación limpia de la misma versión, y revisión del directorio uploads. Hacer solo una parte de estos pasos garantiza que el backdoor se reinstale.

Conclusión

El ataque via WordPress backdoor mu-plugins no es nuevo, pero en 2026 escaló en sofisticación y escala. El caso de los 30 plugins comprados con backdoors durmientes durante ocho meses cambia el modelo de amenaza: ya no alcanza con «instalar solo plugins conocidos y mantenerlos actualizados», porque el vector puede ser el propio proceso de actualización de un plugin que funcionó bien durante años.

Lo que sí está en tu control: monitoreo activo (no solo instalá Wordfence, configuralo para que te alerte), auditoría periódica de usuarios y archivos en mu-plugins, backups externos verificados, y respuesta rápida ante cualquier señal de anomalía en GSC. Un sitio comprometido que se detecta en 48 horas es recuperable. Uno que lleva tres meses sirviendo spam a Googlebot en silencio tiene meses de recuperación SEO por delante.

Fuentes

• Sucuri Blog — Uncovering a stealthy WordPress backdoor in mu-plugins
• TechCrunch — Someone planted backdoors in dozens of WordPress plugins (abril 2026)
• The Hacker News — Hackers exploit WordPress mu-plugins to hide malicious code
• BleepingComputer — Hackers abuse WordPress mu-plugins to hide malicious code
• WordPress Developer Documentation — Must-Use Plugins