Limpieza de Malware en WordPress: Proceso Paso a Paso

Descubrir que tu WordPress tiene malware genera una reacción comprensible: querer arreglarlo ya, cueste lo que cueste. Pero actuar sin un proceso ordenado puede empeorar las cosas, eliminar síntomas visibles sin cerrar la brecha real por la que entró el atacante solo garantiza que vuelva a pasar.

Esta guía da el proceso completo, en el orden correcto, para limpiar una infección de malware en WordPress sin dejar puertas traseras activas.

Si aún no has confirmado que tu web está comprometida, revisa primero las señales en Cómo Saber si tu WordPress ha Sido Hackeado.

Paso 1: aísla antes de tocar nada

Antes de eliminar cualquier archivo, haz una copia completa del estado actual de la web (aunque esté comprometida). Y “completa” significa las dos mitades: los archivos y la base de datos. El malware casi siempre vive en ambas, y limpiar solo una deja la otra lista para reinfectar.

# Copia de los archivos (desde el directorio raíz del sitio)
tar czf /tmp/sitio-comprometido.tar.gz /ruta/a/wordpress

# Copia de la base de datos
mysqldump -u USUARIO -p BASEDEDATOS > /tmp/bd-comprometida.sql

Esa copia no es para restaurarla tal cual, está infectada. Es tu material de análisis: te deja comparar el “antes” con el “después”, buscar patrones con calma en tu equipo local y volver atrás si durante la limpieza rompes algo legítimo. Trabaja siempre sobre esta copia en un entorno separado (local o un staging aislado), no toqueteando el sitio en vivo a ciegas.

Aísla también la superficie de ataque mientras investigas. Si el hosting lo permite, restringe el acceso al panel y a wp-admin por IP, y desactiva temporalmente la ejecución de PHP en las carpetas donde nunca debería haberlo (típicamente wp-content/uploads), que es donde más shells se esconden:

# En un .htaccess dentro de wp-content/uploads
<Files *.php>
  Require all denied
</Files>

Si tu web genera ventas o leads activamente y necesitas recuperar el servicio de inmediato mientras investigas con calma, valora activar temporalmente un modo de mantenimiento o restaurar un backup limpio anterior a la infección (si existe y está verificado) mientras trabajas en el análisis en un entorno separado. Lo que no debes hacer es dejar la web sirviendo malware a tus visitantes durante días mientras “encuentras un rato” para limpiarla: cada visita comprometida agrava el problema con Google y con tus propios usuarios.

Paso 2: cambia todas las credenciales de acceso

Antes de investigar más a fondo, cambia:

Contraseñas de todos los usuarios de WordPress, especialmente los administradores
Contraseña de acceso a la base de datos
Credenciales de FTP/SFTP
Contraseña del panel de hosting (cPanel, Plesk)
Claves secretas de WordPress (wp-config.php), que puedes regenerar desde el generador oficial de WordPress

Un ataque exitoso puede haber capturado cualquiera de estas credenciales, y seguir usándolas sin cambiarlas deja la puerta abierta para que el atacante vuelva a entrar aunque hayas limpiado el resto.

El detalle de las claves secretas se salta mucha gente y es el que permite las reinfecciones más frustrantes. Las ocho constantes AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY y sus _SALT firman las cookies de sesión. Si no las cambias, cualquier sesión de administrador que el atacante ya tuviera abierta sigue siendo válida después de tu limpieza, has cambiado la cerradura pero le has dejado una copia de la llave. Genera un juego nuevo desde api.wordpress.org/secret-key/1.1/salt/, pégalo en wp-config.php sustituyendo el bloque existente, y de paso todas las sesiones activas (la tuya incluida) se invalidan, que es justo lo que quieres.

Un matiz que vemos entrar por soporte: cambiar la contraseña del usuario de base de datos en el panel del hosting sin actualizar el DB_PASSWORD de wp-config.php deja la web caída con un “Error estableciendo la conexión con la base de datos”. Cambia las dos cosas a la vez y en el mismo orden: primero el usuario en el gestor de BD, después la constante en wp-config.php.

Paso 3: identifica el alcance del compromiso

Revisar archivos modificados recientemente

find /ruta/a/wordpress -type f -mtime -30 -name "*.php"

Este comando (si tienes acceso SSH) lista los archivos PHP modificados en los últimos 30 días, útil para identificar rápidamente archivos que han sido alterados o añadidos recientemente sin tu conocimiento.

También conviene mirar más allá de los .php: los atacantes cuelan puertas traseras en cualquier archivo que el servidor procese. Busca .php escondidos donde no debería haberlos (la carpeta de subidas es el clásico) y archivos con extensión rara o doble:

# PHP dentro de uploads: casi nunca es legítimo
find /ruta/a/wordpress/wp-content/uploads -type f -name "*.php"

# Archivos con nombres sospechosos o extensiones dobles
find /ruta/a/wordpress -type f \( -name "*.php.*" -o -name "*.suspected" \)

Comparar con una instalación limpia

Descarga una copia limpia de la misma versión de WordPress que usas, y compara los archivos del núcleo con los de tu instalación. Cualquier diferencia en archivos del núcleo (que normalmente nunca deberían modificarse manualmente) es una señal fuerte de infección.

Si tienes WP-CLI disponible, este paso es de un solo comando y no requiere descargar nada a mano: verifica los checksums del núcleo contra los oficiales de WordPress.org y te lista exactamente qué archivos no cuadran.

wp core verify-checksums
wp plugin verify-checksums --all

El primer comando cubre el núcleo; el segundo hace lo mismo con todos los plugins del repositorio oficial. Ojo: verify-checksums no cubre el tema ni los plugins de pago (no publican checksums), así que esos hay que revisarlos a mano comparando con una copia recién descargada del proveedor.

Revisar la base de datos

El malware no siempre vive solo en archivos, algunas infecciones inyectan código directamente en la base de datos, en el contenido de entradas, widgets o campos de opciones. Revisa especialmente la tabla wp_options en busca de entradas que no reconozcas, y el contenido de entradas y páginas en busca de código extraño insertado (a menudo oculto con CSS para no ser visible).

Patrones de código que delatan una infección

Saber qué buscar acelera todo lo demás. La mayoría del malware de WordPress se apoya en un puñado de funciones de PHP para ejecutar código camuflado. No son ilegales por sí mismas (algún plugin legítimo las usa), pero encontrarlas ofuscadas y en archivos que no deberían tenerlas es una señal muy fuerte:

grep -rEl --include="*.php" \
  "eval\(|base64_decode\(|gzinflate\(|str_rot13\(|create_function\(|\\\$_(POST|REQUEST|COOKIE)\[" \
  /ruta/a/wordpress

eval() combinado con base64_decode() o gzinflate() es el patrón estrella: sirve para desempaquetar y ejecutar una carga oculta que a simple vista es una cadena ilegible de caracteres. Cuando además leen de $_POST, $_REQUEST o $_COOKIE, suele tratarse de una shell que espera órdenes del atacante. Abre cada archivo que salga en la lista y decide con cabeza: un plugin de caché usando base64 en su lugar es normal; una línea larguísima de código ofuscado inyectada al principio de index.php o wp-config.php, no.

Revisa también los tres puntos que el malware modifica una y otra vez para persistir:

Ubicación	Qué buscar
`.htaccess` (raíz y subcarpetas)	Redirecciones a dominios extraños, reglas que envían a móviles a otra web
`wp-config.php`	Código añadido antes de la línea `require_once ... wp-settings.php`
`index.php` del tema o de la raíz	`include`/`eval` de archivos con nombres sin sentido

Paso 4: elimina el código malicioso

Archivos añadidos que no forman parte de WordPress ni de tus plugins/tema legítimos: elimínalos tras confirmar que no son legítimos.
Archivos del núcleo modificados: sustitúyelos por las versiones limpias oficiales.
Código inyectado en la base de datos: elimínalo del contenido afectado, verificando que no rompes funcionalidad legítima al hacerlo.
Usuarios administradores no reconocidos: elimínalos inmediatamente tras confirmar que no son legítimos.
Tareas programadas (cron) no reconocidas: algunos ataques instalan tareas programadas propias para mantener la infección activa incluso tras limpiar los archivos visibles.

Paso 5: cierra la brecha de entrada

Limpiar el malware sin identificar cómo entró garantiza que vuelva a pasar. Las vías de entrada más habituales:

Vía de entrada	Cómo cerrarla
Plugin o tema desactualizado con vulnerabilidad conocida	Actualizar inmediatamente o eliminar si no tiene parche disponible
Contraseña débil o reutilizada	Forzar contraseñas robustas y activar 2FA
Archivo subido malicioso a través de un formulario mal configurado	Revisar y restringir qué tipos de archivo se pueden subir
Acceso FTP/hosting comprometido en otro servicio	Cambiar credenciales y revisar otros servicios que compartan la misma contraseña

Paso 6: verifica que la limpieza fue completa

Tras la limpieza, repite el escaneo con un plugin de seguridad y revisa nuevamente las señales de Cómo Saber si tu WordPress ha Sido Hackeado. Una infección mal limpiada puede reaparecer días después si quedó algún componente activo sin detectar.

No des la limpieza por buena solo porque “la web ya se ve bien”. Muchas infecciones no se muestran al administrador que ha iniciado sesión: sirven la carga maliciosa solo a visitantes que llegan desde Google o a usuarios de móvil. Comprueba el sitio desde una ventana de incógnito, sin sesión iniciada, y desde el móvil. Otro chequeo rápido y revelador: mira el código fuente de tu portada en busca de scripts o iframes que apunten a dominios que no reconoces, y repite el find de archivos modificados de los últimos días, si vuelve a aparecer algo nuevo que tú no tocaste, la brecha sigue abierta y el atacante está reinfectando en tiempo real.

Cuándo la reinfección viene de fuera de tu web

Si limpias a conciencia y el malware vuelve en cuestión de horas, el problema puede no estar en tu WordPress. En hosting compartido, una web vecina comprometida dentro de la misma cuenta puede reinfectar a todas las demás a través de archivos con permisos demasiado abiertos. Y si el atacante dejó una tarea cron a nivel de servidor (no dentro de WordPress) o un proceso corriendo, reescribirá tus archivos limpios una y otra vez.

Cuando la reinfección insiste pese a una limpieza correcta, revisa: otras webs alojadas en la misma cuenta de hosting, las tareas cron del sistema (crontab -l del usuario del hosting), y los permisos de archivos y carpetas (los ficheros deberían ser 644 y las carpetas 755, nunca 777). Este es el escenario en el que una limpieza manual “de la web” no basta y hace falta mirar el servidor entero.

Paso 7: recupera tu reputación con Google

Si Google marcó tu web como comprometida en Search Console, tras confirmar que la limpieza está completa, solicita una revisión manual desde la propia herramienta. Este proceso puede tardar varios días, y no debe iniciarse hasta estar seguro de que la infección se ha eliminado por completo, solicitar la revisión con el problema aún activo puede alargar el proceso de recuperación.

Tabla resumen del proceso completo

Paso	Acción
1	Aislar y hacer copia del estado actual comprometido
2	Cambiar todas las credenciales de acceso
3	Identificar el alcance (archivos, base de datos, usuarios)
4	Eliminar el código malicioso identificado
5	Cerrar la vía de entrada específica
6	Verificar que la limpieza fue completa
7	Solicitar revisión de Google si fue marcado como comprometido

Cuándo pedir ayuda profesional en lugar de hacerlo tú mismo

Si no tienes experiencia técnica identificando código malicioso, o si el compromiso afecta a una tienda con datos de pago de clientes, el riesgo de una limpieza incompleta (dejando puertas traseras sin detectar) es alto. Es exactamente el tipo de incidencia que gestionamos dentro de Gestión WordPress, con el proceso completo de limpieza y cierre de la vía de entrada, no solo eliminación de síntomas visibles.

Preguntas Frecuentes

¿Puedo simplemente restaurar un backup en lugar de limpiar manualmente? Sí, si tienes un backup verificado anterior a la infección, es a menudo más rápido y seguro que limpiar manualmente, siempre que confirmes que ese backup específico no contiene ya la infección.

¿Cuánto tiempo tarda Google en retirar el aviso de sitio pirateado tras la limpieza? Varía, pero puede tardar varios días tras solicitar la revisión manual en Search Console, y solo debe solicitarse cuando la limpieza esté confirmada como completa.

¿Es seguro seguir usando la misma instalación tras limpiarla, o debería reinstalar todo desde cero? Si sigues el proceso completo (incluyendo cierre de la vía de entrada) y verificas que no quedan rastros, no es estrictamente necesario reinstalar desde cero, aunque en compromisos muy graves algunos profesionales prefieren esa opción por seguridad adicional.

¿Cómo sé si el malware afectó también a mis copias de seguridad? Revisa la fecha de creación de tus backups frente a cuándo estimas que ocurrió el compromiso, cualquier backup posterior a esa fecha puede contener ya la infección.

¿Debo notificar a mis clientes si sus datos pudieron verse afectados? Si hay datos personales potencialmente comprometidos, el RGPD establece obligaciones de notificación tanto a la AEPD como, en ciertos casos, a los propios afectados, dentro de plazos concretos.

¿Un plugin de seguridad detecta y limpia automáticamente el malware? Algunos ofrecen limpieza automatizada básica, pero para infecciones más sofisticadas (con puertas traseras ocultas o modificaciones en la base de datos) suele ser necesaria revisión manual adicional.

¿Puedo prevenir que esto vuelva a pasar solo con un buen plugin de seguridad? Ayuda, pero la prevención real combina mantenimiento actualizado, contraseñas robustas con 2FA, y monitorización activa, ningún plugin sustituye por completo estas prácticas.

¿Cuánto cuesta en tiempo una limpieza completa hecha correctamente? Depende de la gravedad, pero un proceso cuidadoso (identificación, limpieza, cierre de brecha, verificación) suele requerir varias horas de trabajo técnico especializado, no una tarea de minutos.

¿Necesito acceso SSH para limpiar el malware o puedo hacerlo solo por FTP? Se puede por FTP, pero es mucho más lento y a ciegas. Con SSH ejecutas los comandos de búsqueda (find, grep, wp core verify-checksums) que localizan los archivos infectados en segundos; por FTP tendrías que ir carpeta por carpeta a ojo. Si tu hosting no da SSH, al menos apóyate en un plugin de escaneo para el trabajo pesado de detección.

¿Debería subir el nivel de PHP o de WordPress durante la limpieza? Aprovecha para dejar el núcleo, los plugins y el tema en su última versión y el PHP en una versión soportada: muchas infecciones entran precisamente por software desactualizado, así que actualizar es parte de cerrar la brecha, no un extra opcional.

¿Y si el malware está también en el propio backup del hosting? Es lo habitual si la infección lleva tiempo. Por eso importa saber cuándo entró: cualquier copia posterior a esa fecha puede estar contaminada. Un backup externo con retención de varios días te da margen para retroceder a un punto anterior al compromiso; el backup del propio hosting, con una o dos copias, rara vez llega tan atrás.

¿Cambiar de contraseña de administrador desde el propio wp-admin es suficiente? No por sí solo. Cambiar la contraseña sin regenerar las claves secretas de wp-config.php deja válidas las sesiones que el atacante ya tuviera abiertas. Cambia contraseñas y claves secretas: son cosas distintas y hacen falta las dos.

Conclusión

Limpiar malware de WordPress no es solo borrar lo que se ve, es un proceso completo que incluye identificar el alcance real, cerrar la vía de entrada específica, y verificar que no queda nada activo. Saltarse cualquiera de estos pasos suele significar que el problema vuelve a aparecer semanas después.

Si prefieres no enfrentarte a este proceso bajo presión, en Avantys lo gestionamos completo dentro de Gestión WordPress, con backups verificados que reducen drásticamente el tiempo de recuperación si algo llega a pasar.