Limpias tu WordPress y el malware vuelve: por qué y qué hacer

Borras el archivo sospechoso, pasas el plugin de seguridad y la web queda limpia. Al rato, el archivo está otra vez ahí. Lo borras de nuevo y vuelve. No es mala suerte, ni que el plugin sea malo: casi siempre significa que lo que has borrado era solo una de las copias.

El mejor ejemplo reciente es SC, un malware para WordPress que Sucuri documentó el 30 de septiembre de 2026. En el caso que analizaron, la puerta trasera regresaba a los pocos segundos de cada borrado. Sirve para entender qué pasa y, sobre todo, en qué orden hay que limpiar, porque el orden es justo lo que suele fallar.

Por qué vuelve: no hay una sola copia

SC guarda su código en al menos ocho sitios a la vez, y cada uno puede reconstruir a los demás. Borras el plugin y otro archivo lo reescribe. Borras ese archivo y lo reescribe el tema. Limpias todos los archivos y, en la siguiente visita, todo se restaura desde la base de datos o desde la memoria del servidor.

Además, SC crea un administrador que no aparece en la pantalla de usuarios y falsifica cookies de inicio de sesión para entrar sin contraseña. Puede inyectar JavaScript en la web, lo que en una tienda permite robar datos en el pago, y borrar plugins de seguridad. Recibe las órdenes a través de la red de Ethereum, usando unos veinte servicios públicos: bloquear uno solo no sirve de nada.

Y no es un caso aislado. Sucuri también ha visto variantes que usan disparadores (triggers) de la base de datos para recrear al administrador cada vez que lo borras. La campaña que analizó Patchstack en octubre instala varias entradas a la vez y falsea las fechas de sus archivos para que parezcan antiguos, así que buscar «lo modificado recientemente» no siempre los encuentra.

Las otras tres razones

A veces no es que quede una copia oculta, sino algo más simple:

• La puerta sigue abierta. Si no has corregido el fallo por el que entraron, volverán a entrar. Por eso saber cómo entraron es parte de la limpieza.
• Las contraseñas siguen siendo válidas. Quien ejecuta código en tu servidor puede leer wp-config.php. Si no cambias las claves, tiene llave.
• La copia de seguridad estaba infectada. Restauras una copia posterior a la entrada y recuperas al intruso con ella.

Sucuri lo resume en una regla útil: si un archivo reaparece, la limpieza no ha terminado. No vuelvas a borrar el mismo archivo. Busca lo que lo está recreando.

El orden importa

Este es el orden que propone Sucuri para SC, con dos pasos previos y dos finales que aplican a cualquier infección. Los nombres de los archivos cambian de una web a otra, así que no sirve buscar uno concreto. Necesitas acceso a los archivos y a la base de datos, y un error aquí puede dejar la web caída: si no te manejas con esto, para en el paso 1 y pide ayuda.

1. Guarda una copia tal como está. Archivos, base de datos y registros del servidor. Es tu red si algo se rompe y la única pista de cómo entraron. Guárdala fuera de la carpeta pública.
2. Desactiva la ejecución antes de borrar. Si hay un auto_prepend_file, vacía primero el archivo al que apunta y luego quita la directiva de .user.ini, php.ini y .htaccess. PHP guarda ese valor en caché hasta 300 segundos: si borras el archivo mientras tanto, todas las peticiones PHP de la cuenta fallan.
3. Limpia primero lo que no está en archivos. La fila de wp_options, las opciones y transitorios del malware, y el segmento de memoria compartida. En un hosting compartido, ese segmento puede pertenecer a otra cuenta y solo el proveedor podrá quitarlo; deja de ser peligroso cuando desaparecen los archivos que lo leen.
4. Quita tareas programadas y disparadores. Si queda un disparador, el administrador volverá aunque restaures todos los archivos.
5. Elimina las cuentas ocultas. Las que aparecen en la consulta de abajo y no en el panel.
6. Borra los archivos de una sola pasada. Cargadores, las dos copias del plugin falso, el ZIP de restauración y los db.php y advanced-cache.php maliciosos. Del functions.php quita solo el bloque añadido: el resto del tema es legítimo.
7. Cierra la entrada y cambia todas las claves. Actualiza lo vulnerable. Después cambia las contraseñas de hosting, base de datos y administradores, y las claves de wp-config.php. Eso último cierra todas las sesiones.
8. Vuelve a escanear y vigila. Mira las mismas rutas durante varios días. Si algo reaparece, vuelve al paso 3.

Tres comprobaciones que el panel no te da

Hazlas desde phpMyAdmin o por SSH. Son solo lecturas, no cambian nada. Si tu base de datos no usa el prefijo wp_, cámbialo también en wp_capabilities.

Cuentas con permisos altos. Compara el resultado con lo que ves en la pantalla de usuarios. La consulta de Patchstack busca administradores; añado dos permisos porque en el caso de UpdraftCentral la cuenta figuraba como Editor, con permisos extra.

SELECT u.user_login, u.user_email, u.user_registered
FROM wp_users u
JOIN wp_usermeta m ON m.user_id = u.ID
WHERE m.meta_key = 'wp_capabilities'
  AND (m.meta_value LIKE '%administrator%'
    OR m.meta_value LIKE '%manage_options%'
    OR m.meta_value LIKE '%install_plugins%');

Disparadores. Lo normal en un WordPress corriente es que no devuelva ninguno. Si aparece alguno y no sabes de qué plugin es, investígalo antes de seguir.

SELECT TRIGGER_NAME, EVENT_OBJECT_TABLE
FROM information_schema.TRIGGERS
WHERE TRIGGER_SCHEMA = DATABASE();

Opciones muy grandes. Una fila de nombre aleatorio con un bloque enorme de texto es mala señal. Muchas opciones grandes son legítimas, así que no borres nada solo por su tamaño.

SELECT option_name, LENGTH(option_value) AS tamano
FROM wp_options
ORDER BY tamano DESC
LIMIT 20;

Si tienes WP-CLI, wp core verify-checksums y wp plugin verify-checksums --all comparan los archivos con los originales. wp cron event list enseña las tareas programadas. Ojo: los plugins de pago no suelen poder comprobarse así, y algunas de estas órdenes cargan WordPress y, con él, el malware. --skip-plugins --skip-themes reduce lo que se ejecuta, pero no frena mu-plugins ni db.php.

¿Y si restauro una copia?

Es a menudo la vía más rápida, con condiciones. Tiene que ser anterior a la entrada, y las fechas de los archivos no bastan para saberlo. Hay que restaurar también la base de datos: restaurar solo archivos deja la fila, las tareas y los disparadores. Y, aun así, hay que cerrar la entrada y cambiar las claves el mismo día, o volverán por el mismo sitio. Perderás lo que haya cambiado desde esa fecha, algo serio en una tienda con pedidos.

Cuándo no hacerlo por tu cuenta

Pide ayuda si la web cobra o guarda datos de clientes, si hay código que no entiendes o si ya lo has intentado una vez y ha vuelto. Si una tienda ha podido exponer datos de pago, no te quedes en la limpieza: habla con tu pasarela. Y si ha habido una brecha de datos personales, el RGPD da 72 horas para notificarla a la AEPD cuando supone un riesgo para las personas, así que consúltalo pronto.

Qué no sabemos

• Cuántas webs tiene SC. Sucuri describe lo que encontró al limpiar, sin dar cifras de alcance.
• Por dónde entra. Su análisis se centra en cómo se queda, no en una vía de entrada concreta. Sucuri recuerda que la mayoría de los casos que atiende vienen de fallos conocidos ya corregidos.
• Si tu web tiene justo esto. Esta guía se basa en informes de Sucuri y Patchstack, no en un análisis propio de SC. Otra infección puede usar otros escondites, aunque la lógica de limpiar es la misma.

Y ahora, qué

Si tu malware ha vuelto, no borres el archivo otra vez: haz la copia y mira las tres comprobaciones de arriba. Para saber qué se ha estado explotando este año, tienes nuestro repaso a los ataques de 2026 y el caso de Bricksforge, con las pistas concretas de ese fallo.

Si prefieres que lo mire alguien, en AGENCIA RSE hacemos limpieza de malware en WordPress: primero averiguamos cómo entraron y dónde se han quedado, y después limpiamos.

Si ves un dato desactualizado, escríbenos y lo corregimos.