WordPress hackeado: qué hacer para recuperarlo, limpiarlo y evitar que se reinfecte

Si tu web en WordPress empezó a redirigir a páginas raras, aparecen URLs tipo casino/medicinas en Google, ves usuarios admin que no creaste o tu hosting te avisó de malware, lo más probable es que tu sitio esté comprometido. Y aquí va la verdad incómoda: en WordPress el problema casi nunca es “un archivo suelto”, sino una puerta abierta (plugin vulnerable, credenciales filtradas, tema nulled, acceso FTP expuesto) que permite reinfección.

En este bloque vas a lograr 3 cosas concretas:

Confirmar si realmente es un hack (y qué tipo).
Cortar el acceso del atacante antes de “limpiar”.
Preparar el terreno para una limpieza segura sin romper tu sitio.

Importante: no te apures a instalar “plugins milagro” ni a borrar archivos al azar. La mayoría de reinfecciones ocurren porque la gente limpia “por encima” sin cerrar la vía de entrada.

Índice

Señales típicas de un WordPress hackeado (y qué significan)
Antes de limpiar: contención urgente (para que no te sigan metiendo cosas)
Haz un respaldo “para evidencia” antes de tocar archivos
Identifica el “tipo de hack” (te ahorra horas en la limpieza)
Lecturas relacionadas para seguir (cluster WordPress)
Limpieza segura por capas (sin romper tu sitio)
El punto crítico: evitar reinfección (la diferencia entre “arreglé” y “se arregló”)
Validación final: cómo saber si quedó limpio
Lecturas relacionadas (para profundizar sin canibalizar)

Señales típicas de un WordPress hackeado (y qué significan)

Estas son las señales más comunes, con la interpretación más probable:

Redirecciones (solo a veces, o solo desde celular): suele ser inyección en JavaScript, .htaccess alterado o malware que detecta el user-agent.
SEO spam (URLs raras indexadas que tú no creaste): casi siempre hay páginas generadas o código inyectado que sirve contenido spam a Google.
Usuarios admin desconocidos o cambios de permisos: indica acceso a wp-admin o creación de cuentas vía backdoor.
Archivos modificados (wp-config.php, index.php, functions.php): típico de backdoors y persistencia.
Alertas del hosting, bloqueo o “malware detected”: el servidor encontró patrones (a veces reales, a veces falsos positivos, pero hay que revisar).
Sitio marcado como peligroso en navegadores: puede ser malware real o inyección que dispara listas de seguridad.

Si tienes 2 o más de estas señales, lo correcto es asumir “compromiso” y ejecutar el plan de contención.

Antes de limpiar: contención urgente (para que no te sigan metiendo cosas)

Este paso es el que más gente se salta… y por eso el malware “vuelve” aunque creas que lo quitaste. La limpieza sirve de poco si el atacante sigue con acceso.

1) Pon el sitio en modo mantenimiento (temporal)

No necesitas complicarte: la idea es reducir daño y evitar que Google rastree contenido infectado mientras trabajas.

Si tienes un plugin de mantenimiento confiable ya instalado, úsalo.
Si no, lo mínimo es mostrar una página simple (aunque sea desde el hosting) mientras resuelves.

Tip práctico: si el hack está generando spam o redirecciones, no conviene dejar el sitio “vivo” horas mientras haces pruebas.

2) Cambia contraseñas críticas (en este orden)

Si el atacante entró por credenciales robadas, esto le corta el camino de vuelta.

Hosting/cPanel (o panel del proveedor)
FTP/SFTP
Base de datos (usuario DB)
WordPress Admin (todos los administradores reales)
Email asociado al dominio (muy importante: con esto resetean todo)

Regla: contraseñas largas y únicas. Si usas la misma en varios sitios, el problema se propaga.

3) Revisa usuarios administradores y elimina los desconocidos

Ve a Usuarios en WordPress (si puedes entrar) y busca:

Admins que no reconoces
Usuarios con nombres raros o correos desconocidos
Roles cambiados (un editor que ahora es admin)

Muy importante: antes de borrar, toma nota del usuario/correo para evidencia. A veces sirve para entender cómo entraron.

4) Revoca accesos “invisibles” (el clásico: llaves guardadas)

Si compartiste accesos con freelancers/agencias en el pasado, o usaste plugins de acceso remoto, asume que una credencial pudo filtrarse.

Cambia credenciales y elimina cuentas que ya no deberían existir.
Si hay cuentas FTP antiguas, bórralas o desactívalas.

Haz un respaldo “para evidencia” antes de tocar archivos

Suena raro, pero es clave: antes de limpiar, guarda una copia del estado actual. ¿Por qué?

Si rompes algo, puedes comparar y recuperar archivos críticos.
Si hay reinfección, puedes identificar qué volvió a aparecer.
Si necesitas soporte del hosting, ayuda tener evidencia.

Qué respaldar como mínimo:

La carpeta wp-content completa (plugins, themes, uploads).
La base de datos.
Archivos raíz: wp-config.php y .htaccess (si existen).

Consejo: guarda el backup fuera del servidor (tu PC o almacenamiento externo). Si lo dejas en el mismo hosting, no es “respaldo”, es otra copia vulnerable.

Identifica el “tipo de hack” (te ahorra horas en la limpieza)

Sin capturas y sin herramientas raras, puedes hacer un diagnóstico rápido:

Si hay redirecciones: sospecha de .htaccess, inyección en header/footer del tema, o scripts inyectados.
Si hay SEO spam indexado: sospecha de páginas/plantillas generadas y contenido servido a bots (a veces solo Google lo WordPress muestra).
Si hay admin desconocido: sospecha de credenciales filtradas, plugin vulnerable o backdoor.
Si el hosting detectó malware: puede estar en uploads, en plugins nulled, o en archivos de tema.

Deja esto listo porque en el siguiente bloque vamos a limpiar por capas (core, plugins/temas, uploads, backdoors) y luego a cerrar la puerta para que no vuelva.

Lecturas relacionadas para seguir (cluster WordPress)

Limpieza segura por capas (sin romper tu sitio)

Ahora sí: limpiar. La idea es hacerlo por capas para que no te quedes con “sensación de limpieza” mientras el backdoor sigue vivo. Si en algún punto encuentras algo demasiado raro, no borres a ciegas: primero renombra (por ejemplo, archivo.php → archivo.php.bak) y valida si el sitio vuelve a la normalidad.

Capa 1: WordPress core limpio (wp-admin y wp-includes)

Una forma muy efectiva de eliminar modificaciones al núcleo es reemplazar los archivos core por una copia limpia, manteniendo tu contenido y configuración.

Qué se reemplaza: carpetas wp-admin y wp-includes por versiones limpias.
Qué NO se toca: wp-content (tus temas, plugins, uploads) y wp-config.php.

Este enfoque se recomienda con frecuencia en soporte de WordPress (re-subir core limpio y reemplazar archivos raíz como wp-login.php excepto wp-config.php y .htaccess si lo usas).
Referencia (WordPress.org Support)

Por qué funciona: si te inyectaron cosas en archivos del core, se van de inmediato. Pero ojo: si la entrada fue por plugin vulnerable o credenciales, igual debes cerrar esas puertas (y ya lo hiciste en el bloque anterior).

Capa 2: Plugins y temas (la causa #1 real)

En la práctica, la mayoría de hacks de WordPress vienen por:

Plugins desactualizados con vulnerabilidades conocidas
Temas o plugins “nulled” (piratas) que traen backdoors
Plugins abandonados/inactivos que quedaron instalados

Plan rápido:

Elimina plugins/temas que no uses (incluso si están inactivos).
Actualiza todo lo que sí uses (core + plugins + tema).
Reinstala desde fuente oficial los plugins/temas críticos (descarga limpio y reemplaza).

Señal de que ibas por buen camino: al borrar un plugin “sospechoso”, desaparecen redirecciones, ventanas raras o scripts inyectados.

Capa 3: Backdoors escondidos (donde casi siempre se reinfecta)

Cuando un sitio “vuelve a infectarse” a los días, normalmente quedó un backdoor en uno de estos lugares:

wp-content/uploads/ con archivos .php camuflados (muy común).
mu-plugins (plugins “must-use”) si existe esa carpeta.
Archivos del tema: functions.php, header.php, footer.php.
Archivos raíz raros con nombres aleatorios (ej: wp-old.php, cache1.php).

Qué buscar (patrones típicos): textos como base64_decode, eval, cadenas largas ofuscadas, llamadas externas raras, y scripts que se “inyectan” en el HTML.

Ojo: no todo base64 es malware, pero en hacks reales suele aparecer junto con ofuscación y comportamiento extraño.

Capa 4: Redirecciones y “SEO spam” (si Google indexó basura)

Si tu problema es que WordPress redirige o se ven URLs spam en Google, revisa estos puntos clave:

.htaccess (si lo usas): busca reglas desconocidas, redirects raros o bloques enormes que no recuerdas.
Inyección JS en tema o plugins: scripts que cargan cosas externas o detectan bots.
Contenido servido solo a Google: a veces el spam no se ve cuando tú visitas normal, pero sí cuando rastrea un bot.

Después de limpiar, entra a Search Console y revisa el Security issues report (si Google detectó hack/malware):
Security issues report (Google Search Console)

Si quedaron URLs spam indexadas, puedes usar el reporte de Removals (ocultación temporal mientras arreglas definitivamente):
Removals report (Google)

Regla SEO importante: esas URLs spam deben terminar dando 404 o 410 o desaparecer de verdad; el removal ayuda, pero no reemplaza la limpieza real.

El punto crítico: evitar reinfección (la diferencia entre “arreglé” y “se arregló”)

Este es el tramo que define si tu web queda estable o si en 7 días vuelves al infierno.

1) Asegura el panel de WordPress (hardening básico)

WordPress tiene una guía oficial de hardening con prácticas recomendadas:
Hardening WordPress (oficial)

Acciones que suelen dar el mayor impacto con el menor esfuerzo:

Desactiva el editor de archivos desde el panel (evita que un intruso edite plugins/temas desde wp-admin).

En wp-config.php (idealmente cerca de otras constantes), añade:

define('DISALLOW_FILE_EDIT', true);

Activa 2FA para administradores (si usas plugin confiable).
Limita intentos de login (reduce brute force).

2) Revisa permisos de archivos y elimina “sobras”

Elimina plugins/temas que no uses.
Evita dejar backups viejos como .zip en la raíz del sitio (son un regalo para atacantes).
Si encuentras .php dentro de uploads sin razón clara, es altamente sospechoso.

3) Añade una capa WAF/CDN (cuando quieres dormir tranquilo)

Una capa WAF puede bloquear patrones de ataque comunes y ayudar a frenar explotación automática de vulnerabilidades.

Referencia general:
Cloudflare WAF (overview)
y documentación:
Cloudflare WAF Docs

Nota realista: un WAF no reemplaza actualizar plugins ni arreglar credenciales, pero sí reduce el “ruido” y ataques automáticos.

Validación final: cómo saber si quedó limpio

Tu sitio ya no redirige (prueba desde celular y modo incógnito).
No aparecen usuarios admin extraños.
No hay filtros raros de reenvío (si tienes emails asociados) ni cambios de configuración inesperados.
Search Console deja de mostrar alertas de seguridad (si existían).
El hosting deja de detectar malware (si te avisaba).

Consejo práctico: si limpiaste pero el hack regresa, no lo tomes como “mala suerte”: casi siempre quedó un backdoor o hay un plugin vulnerable que volvió a abrir la puerta.

Lecturas relacionadas (para profundizar sin canibalizar)

Deja una respuesta Cancelar la respuesta