WordPress reinfectado con malware: por qué vuelve

En pocas palabras: Un WordPress reinfectado vuelve a mostrar malware casi siempre porque el backdoor original sigue activo en wp-content/uploads, temas o plugins, o porque las credenciales comprometidas nunca se cambiaron del todo. Borrar archivos visibles no cierra la vulnerabilidad; herramientas como Wordfence ayudan a detectarla.

El malware que reinfecta un WordPress recién limpiado casi siempre indica que el backdoor original sigue activo, las credenciales comprometidas nunca se cambiaron del todo, o la vulnerabilidad que dejó entrar al atacante nunca se cerró. No vuelve solo: entra por la misma puerta que quedó abierta.

Un WordPress reinfectado es un sitio que vuelve a mostrar malware, redirecciones o spam SEO después de una limpieza previa, generalmente porque el punto de entrada original (un backdoor, un plugin vulnerable o una credencial robada) sigue activo. Borrar los archivos visibles no equivale a cerrar la vulnerabilidad que permitió el primer ataque.

¿Por qué la limpieza de malware no siempre elimina la amenaza en WordPress?

Borrar el archivo que aparece marcado como malicioso no cierra la puerta por la que entró el atacante. Es la razón por la que tantos sitios «se limpian», andan bien un par de semanas y después vuelven las redirecciones, el aviso de Google o el spam en los resultados de búsqueda.

El problema casi nunca es casualidad. Según el análisis de Alsnippets sobre reinfecciones, que cita la guía de Sucuri sobre por qué un sitio sigue siendo hackeado, si no se elimina el punto de entrada original el sitio vuelve a caer tarde o temprano. Las causas más comunes que encuentran en sus auditorías son backdoors activos ocultos, credenciales comprometidas, plugins vulnerables sin actualizar, permisos de archivos mal configurados y hosting compartido con mala aislación entre cuentas. Cualquiera que haya administrado un sitio con varios clientes en el mismo servidor sabe lo rápido que un problema de aislación se convierte en varios sitios infectados a la vez. Y ojo: cada reinfección suele ser más agresiva que la anterior.

Subís el sitio a un hosting nuevo, cambiás la contraseña, instalás un plugin de seguridad, escaneás una vez, ves que sale limpio y confiás, pero el atacante nunca necesitó tu contraseña nueva porque dejó un backdoor escondido en una carpeta de uploads que ese escaneo ni tocó.

¿Qué es un backdoor y por qué permite que el malware vuelva?

Un backdoor es un script que un atacante deja escondido en el servidor para volver a entrar sin repetir el ataque original. Es una llave duplicada: aunque cambies la contraseña de WordPress, el atacante entra por la puerta trasera que nadie encontró.

Según la guía técnica de Nexbu, publicada en marzo de 2026, estos scripts suelen ocultarse en carpetas como wp-content, uploads, themes y plugins, con nombres de archivo diseñados para pasar desapercibidos entre los archivos legítimos del core. La lógica del atacante es simple: cuantos más lugares para esconder el backdoor, más difícil resulta encontrarlos todos en una sola pasada.

¿Alguien revisa manualmente cada archivo de wp-content/uploads? Casi nadie. Y ahí es exactamente donde se esconden. Esto se conecta con lo que analizamos en comparar Wordfence y Sucuri antes de decidir.

En Alsnippets, antes de borrar nada, revisan usuarios de WordPress activos, accesos FTP y del panel de hosting, cron jobs sospechosos, archivos ocultos, la integridad del core y la base de datos. Ese orden importa: si empezás borrando archivos sin saber por dónde entró el atacante, el ciclo se repite.

Ejemplo hipotético: qué pasa cuando se borra antes de diagnosticar

El siguiente escenario es ilustrativo, no un caso real, y sirve para mostrar cómo se aplica el orden «diagnóstico antes que borrado» que describen las fuentes citadas.

Imaginemos un sitio ficticio, «tienda-ejemplo.com», que un lunes amanece con el aviso de Google de «sitio peligroso». El administrador entra en pánico, borra un archivo con nombre raro que encuentra en el tema activo, instala un plugin de seguridad y da por cerrado el caso. El aviso de Google desaparece a los pocos días.

Dos semanas después, el mismo aviso vuelve a aparecer, junto con redirecciones hacia páginas de apuestas. ¿Qué pasó? Siguiendo la lógica que describen Alsnippets y Nexbu, lo más probable en un caso así es que el archivo borrado fuera solo la parte visible del ataque: el backdoor real seguía escondido en wp-content/uploads (una carpeta pensada para imágenes, no para código PHP), y la contraseña de FTP —nunca cambiada— seguía siendo la misma que usó el atacante la primera vez.

Si en lugar de borrar primero, el administrador hubiera empezado por el orden diagnóstico que proponen las fuentes —revisar usuarios activos, accesos FTP y de hosting, cron jobs, integridad del core y base de datos antes de tocar un solo archivo—, probablemente habría encontrado el script oculto en uploads y la credencial de FTP comprometida en la primera pasada, en lugar de en la segunda. La diferencia no está en la herramienta que se usa, sino en el orden: diagnóstico primero, borrado después, refuerzo al final.

¿Cómo se esconde el malware dentro de la base de datos de WordPress?

El malware que se aloja en la base de datos no se ve al revisar archivos, porque vive en tablas como wp_posts, wp_options y wp_users. Podés reinstalar el core entero, cambiar cada tema y plugin, y el sitio sigue infectado porque el código malicioso está guardado como contenido, no como archivo.

Según Nexbu, en muchos casos el malware se oculta dentro de tablas de opciones o contenido almacenado en la base de datos, y puede reaparecer incluso después de eliminar todos los archivos infectados. El script inyectado se ejecuta cuando WordPress carga esa entrada, aunque el archivo que lo llamó ya no exista.

La limpieza de la base de datos implica revisar manualmente entradas sospechosas en wp_posts, wp_options y wp_users, buscar usuarios administradores creados sin autorización y sacar cualquier script inyectado en el contenido. Es trabajo de lupa, no de plugin con un clic.

¿Qué archivos y carpetas hay que revisar para detectar código malicioso persistente?

Los archivos con más probabilidad de tener código malicioso persistente son wp-config.php, index.php, el archivo .htaccess y todo lo que esté dentro de wp-content/uploads. Ahí es donde los atacantes, según Nexbu, suelen ocultar scripts diseñados para sobrevivir a una limpieza superficial.

• wp-config.php: guarda las credenciales de la base de datos, y un atacante puede insertar ahí código que se ejecuta antes que cualquier otra cosa en el sitio.
• wp-content/uploads: carpeta pensada para imágenes y archivos, no para código PHP, por eso es un escondite clásico para backdoors.
• Temas y plugins inactivos: nadie los revisa porque «no están en uso», pero siguen siendo archivos PHP que WordPress puede ejecutar si se llaman directamente.
• Archivos .htaccess: pueden tener reglas de redirección maliciosas que solo se activan para ciertos visitantes, por ejemplo los que vienen de Google.
• Archivos con fecha de modificación reciente: compará la fecha contra el momento en que instalaste o actualizaste cada plugin; si algo cambió sin que vos lo tocaras, ahí hay una pista.

¿Qué rol juegan los permisos de archivos y usuarios mal configurados?

Los permisos de archivos en 777 (lectura, escritura y ejecución para cualquiera) son una invitación abierta a que cualquier script modifique tu sitio sin pedir permiso. Sumale usuarios administradores fantasma que el atacante creó durante el primer ataque, y tenés dos vías de reingreso funcionando en paralelo. Ya lo cubrimos antes en cuál de las dos herramientas limpia mejor.

Alsnippets, después de diagnosticar, cambia todas las credenciales, refuerza permisos y elimina plugins innecesarios como parte del proceso de desinfección. Cambiar la contraseña sin revisar antes si hay un usuario administrador oculto (sí, en serio, a veces ni te das cuenta que existe) es como cambiar la cerradura de la puerta principal dejando la de servicio sin tocar.

Revisá la lista de usuarios. Todos. Uno por uno.

Un permiso mal configurado en carpetas críticas, combinado con un usuario administrador que no reconocés, es la combinación perfecta para que el ataque vuelva sin que el atacante tenga que hacer nada nuevo.

¿Cómo hacer una auditoría de seguridad completa después de una reinfección?

Una auditoría completa después de una reinfección arranca comparando los archivos del core contra una instalación oficial de WordPress, sigue con la revisión de logs de acceso y termina escaneando la base de datos en busca de código inyectado. Saltarse alguno de estos tres pasos es la razón por la que tantas limpiezas fallan por segunda vez.

Según la guía de Guardianes WP sobre desinfección de WordPress hackeado, publicada en diciembre de 2025, los errores más comunes que provocan reinfecciones son restaurar una copia de seguridad ya infectada, confiar solo en un plugin de seguridad, no cambiar todas las contraseñas, mantener plugins vulnerables sin actualizar y no revisar la base de datos. Si tu web ya se reinfectó una vez, la fuente advierte que lo más probable es que todavía quede malware oculto en algún lado.

La misma guía da referencias de tiempo y costo que sirven para calibrar expectativas: una infección simple se resuelve en 24 a 48 horas, mientras que un caso avanzado, con spam SEO o penalización de Google, puede tardar entre 2 y 5 días. En cuanto a precio, una limpieza básica arranca desde 400-450 € (impuestos incluidos), y las infecciones múltiples o avanzadas llevan presupuesto a medida.

¿Vale la pena pagar eso? Comparalo con lo que perdés en tráfico SEO y confianza de Google mientras el sitio sigue marcado como peligroso.

Criterios para decidir el orden de tu propia limpieza

Con la información de las tres fuentes citadas se puede armar una regla práctica para decidir por dónde empezar cuando un sitio se reinfecta, en lugar de saltar directamente a borrar archivos:

• Si es la primera infección: escanear, identificar el archivo o plugin comprometido y reforzar credenciales suele alcanzar, siguiendo los pasos que describe Guardianes WP para una limpieza básica.
• Si ya hubo una reinfección previa: conviene invertir el orden y diagnosticar antes de borrar nada: revisar usuarios, accesos, cron jobs, integridad del core y base de datos, tal como describe el proceso de Alsnippets, porque un backdoor ya demostró que sobrevivió a una limpieza anterior.
• Si el sitio genera ingresos o tráfico crítico: el tiempo que toma un diagnóstico manual completo (según Nexbu, revisar archivos, base de datos y backdoors por separado) puede justificar delegar el proceso, sobre todo si no hay experiencia técnica para hacerlo sin apuro.
• Si hay múltiples sitios en el mismo hosting compartido: el diagnóstico no puede limitarse a un solo sitio, porque la mala aislación entre cuentas que señala Alsnippets permite que la reinfección salte de una web a otra dentro del mismo servidor.

La idea de fondo, respaldada por las tres fuentes, es siempre la misma: cuantas más veces se repitió la infección, menos sentido tiene apurar el borrado y más sentido tiene invertir tiempo en entender por dónde entró el atacante la primera vez.

¿Qué medidas evitan que el malware vuelva a infectar el sitio?

Ningún plugin de seguridad reemplaza un mantenimiento activo. Actualizar WordPress, los temas y los plugins apenas sale una versión nueva sigue siendo la medida más efectiva contra la reinfección, y también la que menos gente cumple en la práctica. Complementá con mantener los CVE parcheados a tiempo.

• Actualizaciones sin demora: la mayoría de los ataques automatizados explota vulnerabilidades ya conocidas y parchadas, no fallas de día cero.
• Firewall de aplicaciones web: filtra tráfico malicioso antes de que llegue al servidor, algo que Nexbu recomienda como parte del refuerzo posterior a la limpieza.
• Autenticación en dos pasos: con esto activo, una contraseña filtrada ya no alcanza para entrar al panel de administración.
• Backups verificados: una copia de seguridad hecha durante la infección restaura el malware junto con el contenido, así que hay que confirmar que el backup esté limpio antes de usarlo.
• Monitoreo continuo: detectar un cambio sospechoso en archivos o base de datos a tiempo evita que una reinfección se convierta en una penalización de Google.

El hosting también importa, y bastante. Un plan compartido con mala aislación entre cuentas es, según Alsnippets, una de las causas frecuentes de reinfección: si otro sitio en el mismo servidor está comprometido, el malware puede saltar entre cuentas sin que vos hicieras nada mal. Para sitios que dependen del negocio, vale la pena evaluar un hosting con mejor aislación entre cuentas. No es una solución por sí sola, pero reduce una de las variables que menos controlás vos como administrador del sitio. Sumale monitoreo activo y actualizaciones al día, y el margen para que el ataque vuelva se achica bastante.

Errores comunes al intentar limpiar un WordPress reinfectado

Restaurar una copia de seguridad sin verificarla primero es el error más frecuente. Si el backup se hizo durante la infección, estás reinstalando el malware junto con el contenido. La corrección es simple: escaneá el backup antes de restaurarlo, no después.

Confiar en un solo plugin de seguridad para hacer todo el trabajo también falla seguido. Wordfence, Sucuri o el escáner de tu propio hosting sirven para detectar, según recomienda Guardianes WP, pero ninguna herramienta reemplaza una revisión manual de archivos ocultos, cron jobs y base de datos (spoiler: los escáneres automáticos no llegan a todos lados). Instalarlo pensando que es la «solución mágica» y olvidarte del resto es justo el error que deja la puerta abierta.

No cambiar todas las contraseñas, en todos los accesos, es otro clásico. Cambiar la del panel de WordPress y dejar la de FTP o la de la base de datos igual es dejar una de las puertas sin tocar. Cambiá WordPress, FTP, base de datos y panel de hosting, los cuatro juntos.

Mantener plugins o temas «nulled» (sin licencia oficial) también suma riesgo. Según Guardianes WP, el uso de temas o plugins piratas es una de las causas más habituales de infección. La corrección acá no es técnica, es de hábito: bajá todo de repositorios oficiales.

Preguntas Frecuentes

¿Por qué mi WordPress se reinfecta después de limpiarlo?

Tu WordPress se reinfecta porque la limpieza eliminó los síntomas visibles pero no cerró el punto de entrada original: un backdoor activo, una credencial comprometida o una vulnerabilidad sin parchear. Mientras esa puerta siga abierta, el atacante no necesita hackear de nuevo, simplemente vuelve a entrar por el mismo lugar. Lo explicamos a fondo en reforzar el firewall para bloquear ataques.

¿Cómo sé si todavía tengo un backdoor en mi sitio WordPress?

Revisá si aparecen usuarios administradores que no creaste, archivos PHP recientes en carpetas como uploads, o cron jobs que no configuraste vos. Comparar los archivos del core contra una instalación oficial de WordPress también permite detectar modificaciones que no deberían estar ahí.

¿Qué es un backdoor en WordPress y cómo se elimina?

Un backdoor es un script oculto que le da al atacante acceso al servidor sin pasar por el login normal de WordPress. Se elimina identificando el archivo exacto, generalmente en wp-content, uploads, themes o plugins, borrándolo y reinstalando el core y los plugins desde fuentes oficiales para descartar cualquier otra copia.

¿Qué permisos de archivos debo revisar en un WordPress hackeado?

Los permisos peligrosos son 777 en carpetas y archivos, porque permiten que cualquier proceso lea, escriba y ejecute sin restricción. Lo recomendable es restringir esos permisos a lo mínimo necesario para que el sitio funcione, ajustando los valores exactos según lo que pida tu configuración de hosting.

¿Necesito cambiar de hosting si mi WordPress sigue infectado?

No siempre, pero si estás en un plan compartido con mala aislación entre cuentas y las reinfecciones persisten después de una limpieza correcta, cambiar a un hosting con mejor separación entre sitios y soporte técnico especializado reduce el riesgo. Antes de migrar, confirmá que el sitio esté realmente limpio para no llevar la infección a un servidor nuevo.

Conclusión

Un WordPress reinfectado no es mala suerte, es una limpieza que se quedó a mitad de camino. El malware vuelve porque el backdoor, la credencial comprometida o el plugin vulnerable nunca dejaron de estar ahí, escondidos entre archivos que nadie revisó o filas de una base de datos que ningún escáner mira por default.

Si ya pasaste por una reinfección, la próxima limpieza necesita ser distinta: diagnóstico primero, después borrado, y recién ahí refuerzo de permisos, contraseñas y monitoreo. Si no tenés el tiempo ni la experiencia técnica para hacerlo bien, una desinfección profesional cuesta bastante menos que perder tráfico, clientes y la confianza de Google durante semanas (que no es poco).

Fuentes

• Alsnippets – Por qué tu WordPress se reinfecta después de limpiarlo
• Guardianes WP – Desinfección de WordPress hackeado: guía completa
• Nexbu – WordPress hackeado o infectado con malware: guía técnica completa