¿Cómo eliminar malware de WordPress?

Actualizado el 17/04/2026: Un análisis reciente expone dos fallas estructurales que afectan a todos los escáneres de malware en sitios WordPress reales: los timeouts invisibles que dejan el escaneo incompleto, y la ausencia total de contexto de ataque en los resultados. Si tu escáner llegó al 48% y se detuvo, o si marcó archivos sin decirte si alguien realmente los atacó, este artículo explica por qué pasa y cómo compensarlo.

Si tu WordPress tiene malware, lo más probable es que ya lo sepas sin saberlo: el sitio redirige a farmacias rusas, Google Chrome muestra una advertencia roja, o tu hosting te suspendió la cuenta. Eliminar malware WordPress no es un proceso de cinco minutos, pero tampoco es magia negra. Acá te explico cómo rastrearlo, limpiarlo y cerrarte la puerta para que no vuelva.

Síntomas de que tu WordPress está infectado

Ponele que entrás a tu sitio un lunes a la mañana y Chrome te muestra una pantalla roja con «Este sitio puede dañar tu computadora». O peor: un cliente te escribe preguntando por qué tu web vende Viagra. Esos son los casos evidentes. Los más sigilosos son peores.

Los signos que suelen aparecer primero:

• Redirecciones a sitios externos: el sitio redirige a páginas de farmacia, casino o contenido adulto, especialmente desde mobile o para usuarios que llegan desde Google.
• Alertas de Google Safe Browsing: Google marca el sitio como peligroso en los resultados de búsqueda. Una vez que esto pasa, el tráfico orgánico cae en horas.
• Usuarios administradores desconocidos: aparecen cuentas con nombres raros que vos no creaste. Es uno de los vectores de acceso más comunes.
• Contenido farmacéutico («pharma hack»): las páginas del sitio empiezan a ranquear para keywords de medicamentos. No lo ves en el frontend, pero lo ve Google.
• Sitio lento o con caídas frecuentes: el servidor está generando spam o participando en un botnet. Tu hosting empieza a reportar uso anómalo de CPU.
• Advertencias del hosting: muchos proveedores detectan patrones de malware y suspenden cuentas antes de que vos te des cuenta.

Según datos de AlmCorp, más de 700.000 sitios WordPress fueron comprometidos en 2025. La tasa de infección sigue creciendo en 2026, principalmente por plugins desactualizados y contraseñas débiles.

Cómo buscar y localizar malware en WordPress

Antes de usar cualquier plugin, hay técnicas manuales que te dan una imagen rápida de lo que está pasando.

Archivos modificados recientemente

Si tenés acceso SSH, este comando te muestra los archivos PHP modificados en los últimos 7 días:

find /var/www/html -name "*.php" -mtime -7 -type f

Si ves archivos en wp-content/uploads con extensión .php, es señal de alerta. Los archivos de imágenes no deberían ser ejecutables.

Código ofuscado en los archivos

El malware casi siempre usa ofuscación para esconderse. Los patrones más comunes son base64_decode(), eval(), gzinflate(), str_rot13() y fromCharCode(). Una búsqueda rápida en el servidor:

grep -r "base64_decode" /var/www/html --include="*.php"

Ojo: algunas funciones legítimas también usan base64. El problema es cuando aparece dentro de eval() o en archivos que no deberían tener código PHP, como imágenes o archivos de configuración de tema. Profundizamos sobre esto en nuestro artículo sobre auditar el código de tus plugins personalizados.

Base de datos

El pharma hack clásico inyecta spam en los posts y opciones de WordPress. Conectate a phpMyAdmin y buscá en la tabla wp_options valores en sitemeta, home o siteurl que no reconocés. También revisá wp_posts para contenido con links a farmacéuticas.

Herramientas y plugins para escanear malware

Las herramientas automatizadas aceleran el trabajo, pero ninguna es infalible, especialmente en infecciones sofisticadas donde el malware se camufla como código legítimo.

Wordfence Free alcanza para detectar la mayoría de las infecciones conocidas. El problema es que su base de firmas en la versión gratuita tiene 30 días de retraso respecto a la premium. Para malware reciente, eso puede ser la diferencia entre detectarlo o no.

MalCare usa análisis de señales en el servidor en vez de solo comparar firmas. Detecta más variantes de código ofuscado. Según datos de la industria, en 2025 se registraron más de 11.000 nuevas vulnerabilidades en plugins y temas de WordPress. Con ese volumen, la actualización constante de firmas no es opcional.

Los errores de los escáneres de malware WordPress que nadie te cuenta

El problema de base: herramientas diseñadas para sitios de juguete

Acá está la raíz del asunto: los escáneres de malware se desarrollan y prueban en instalaciones frescas de WordPress. Una instancia limpia, unos doce plugins activos, cuarenta segundos de escaneo y listo. El problema es que eso no existe en producción real.

Un sitio de agencia con tres años de historia tiene entre 60.000 y 80.000 archivos. Si además tiene WooCommerce con catálogo extenso, un page builder y varios temas instalados aunque inactivos, el volumen sube más. Los fabricantes de escáneres no prueban en ese entorno. Prueban en el equivalente a un auto de exposición, no en uno que circuló 200.000 kilómetros por caminos de tierra.

El resultado es predecible: el escáner funciona bien en la demo y falla silenciosamente en producción. Y lo peor es que falla sin avisarte que falló.

Limitación #1: el timeout de 90 segundos que nadie ve

En hosting compartido, el tiempo máximo de ejecución PHP suele estar entre 30 y 90 segundos. Algunas plataformas lo tienen en 60, otras en 30. La propia documentación de Wordfence sobre troubleshooting de escaneo reconoce este problema y recomienda ajustar max_execution_time cuando el escaneo se interrumpe.

Lo que pasa en la práctica es esto: el escáner avanza bien hasta los 48.000 o 50.000 archivos, la request AJAX que maneja el progreso supera el límite de tiempo y muere. Pero el JavaScript de la interfaz no tiene manejo de error para ese caso. Entonces la barra de progreso sigue subiendo. Sigue pareciendo que está trabajando. Y vos esperás mirando un proceso que ya terminó hace rato, sin revisar un solo archivo más. Te puede servir nuestra cobertura de estrategias de defensa en capas.

El resultado: creés que escaneaste el sitio completo. En realidad escaneaste la mitad. Y el malware que se escondió en los últimos 20.000 archivos sigue ahí, tranquilo. Este problema con max_execution_time en WordPress es más frecuente de lo que parece y tiene soluciones concretas, aunque la mayoría de los usuarios no sabe que tiene que buscarlas.

Ahora bien, no todos los proveedores dan acceso a php.ini para modificar ese parámetro. En hosting compartido estándar es común que esté bloqueado. En ese caso, la única opción es dividir el escaneo manualmente por carpetas o usar un escáner que opere fuera del entorno PHP del sitio.

Limitación #2: el escáner detecta el patrón, pero no el ataque

La segunda falla es más conceptual y por eso más difícil de ver. Cuando un escáner marca un archivo como sospechoso, te da algo así: «Archivo X — patrón sospechoso — confianza 78%». Y eso es todo.

No te dice si alguien realmente intentó acceder a ese archivo. No te dice si el firewall registró requests contra esa ruta. No te dice cuándo fue la última vez que ese archivo fue modificado ni si esa modificación coincidió con un período de actividad anómala. El servidor tiene toda esa información. Los logs de Wordfence, los logs de acceso del servidor, los registros del WAF: todo eso está ahí. Pero el escáner no lo consulta.

El contraste práctico: un archivo con código ofuscado que lleva dos años sin ser modificado y nunca apareció en ningún intento de acceso bloqueado es probablemente un falso positivo. Un archivo con el mismo código que fue modificado hace tres semanas y aparece en cinco intentos de acceso fallidos registrados por el firewall es una amenaza real que hay que investigar primero.

Esa distinción el escáner no la hace. Vos tenés que hacerla a mano cruzando fuentes.

Qué revelan los logs de firewall (y el escáner ignora)

Wordfence y Sucuri guardan registros detallados de intentos bloqueados: fuerza bruta sobre wp-login.php, inyecciones SQL, requests con payloads maliciosos, accesos desde IPs marcadas. En dos semanas típicas en un sitio mediano es normal ver decenas de intentos contra wp-login.php desde rangos de IP de Europa del Este, intentos de explotar formularios con parámetros manipulados, o scans automatizados buscando rutas conocidas de plugins vulnerables.

Esa información tiene un valor que el escaneo de archivos no tiene: el contexto temporal. Si el log del firewall muestra que el día 3 de marzo hubo 200 requests fallidas contra un directorio específico, y el escáner marca un archivo en ese directorio como sospechoso, ya tenés una hipótesis concreta para investigar. Si no hay ningún intento registrado contra ese archivo en los últimos seis meses, la probabilidad de falso positivo sube mucho.

Los logs de seguridad en WordPress son una fuente que muchos administradores no consultan hasta que ya tienen un problema. El hábito de revisarlos periódicamente, no solo cuando pasa algo, cambia bastante el panorama defensivo. No porque sean fáciles de leer, sino porque dan señales tempranas de actividad anómala antes de que el malware se instale.

El tema es que hay que ir a buscarlos activamente. La interfaz de Wordfence los muestra en «Firewall > Blocked Attacks». Sucuri los tiene en el dashboard bajo «Audit Logs». No están integrados en el flujo de escaneo, lo cual es exactamente el problema que señalamos.

Pattern matching vs. detección de ataque real: la diferencia que importa

La mayoría de los escáneres actuales funcionan con comparación de firmas. Tienen una base de datos de patrones de código malicioso conocidos y buscan coincidencias en los archivos del sitio. Funciona bien para malware conocido y mal distribuido. Para todo lo demás, tiene limitaciones serias.

El malware moderno usa ofuscación, encriptación y técnicas de evasión que hacen que el patrón no coincida con ninguna firma conocida. Un análisis reciente de la industria estima que alrededor del 23% del malware activo actual evade el detection por firmas. Ese número habría que tomarlo con cierto margen de error según la fuente, pero la dirección es clara: solo con firmas no alcanza.

La alternativa más sólida es el análisis multicapa: firmas + análisis de comportamiento en tiempo real + integridad de archivos + feeds de amenazas actualizados. Algunos escáneres premium se acercan a eso. La integración de IA en herramientas como Wordfence va en esa dirección, aunque todavía hay una brecha entre lo que prometen y lo que entregan en sitios de alta complejidad.

La integridad de archivos merece atención especial. Si sabés exactamente cómo debería verse cada archivo del core de WordPress y podés compararlo contra el estado actual, cualquier diferencia es una anomalía que investigar. Eso es más robusto que buscar patrones de código malicioso, porque no depende de que alguien haya catalogado ese malware específico antes.

Configuración práctica en hosting compartido

Si no podés escapar del hosting compartido por ahora, estas configuraciones reducen el impacto de los timeouts:

• Dividir el escaneo por carpetas: Wordfence permite excluir rutas del escaneo. Podés hacer un escaneo de wp-content/plugins, después uno de wp-content/themes, después de wp-content/uploads por separado. Es tedioso, pero es la única forma de cubrir todo cuando el timeout mata el proceso general.
• Aumentar max_execution_time donde sea posible: si tenés acceso a php.ini o a un archivo .htaccess con permisos, probá subir el valor a 120 o 180 segundos. No todos los proveedores lo permiten, pero vale intentarlo antes de resignarte al valor por defecto de 30 segundos.
• Desactivar plugins de caché durante el escaneo: algunos plugins de caché interceptan las requests AJAX que el escáner usa para mantener el progreso. Desactivarlos temporalmente reduce una fuente de interrupciones.
• Verificar que el escaneo terminó: no des por terminado un escaneo solo porque la barra llegó al 100%. Wordfence muestra un resumen con la cantidad de archivos escaneados. Comparalo con el total de archivos del sitio. Si el número no cierra, el escaneo fue incompleto.

Eso sí: estas son compensaciones para un problema de diseño, no soluciones definitivas. Si el sitio creció lo suficiente como para que un escaneo completo no entre en 90 segundos, probablemente ya sea momento de pensar en hosting con recursos dedicados donde tenés control real sobre los límites de ejecución PHP.

Enfoque multicapa: combinando escáneres con análisis de logs

La conclusión práctica de todo esto es que un escaneo solo, especialmente en un sitio grande, no es suficiente como diagnóstico de seguridad. El enfoque que cierra las brechas es combinar el escaneo por etapas con la revisión de logs de firewall en paralelo.

El proceso concreto: primero ejecutás el escaneo en etapas por carpetas para asegurarte de cubrirlo todo. Cuando el escáner marca algo como sospechoso, antes de actuar vas a los logs del firewall y buscás si ese archivo o esa ruta aparece en algún intento de acceso registrado. Si hay coincidencia temporal entre la modificación del archivo y un período de actividad maliciosa, tenés una amenaza real. Si el archivo lleva dos años sin tocarse y no hay ningún registro de actividad contra él, probablemente sea un falso positivo que podés investigar con más calma. Relacionado: desarrollo de plugins personalizados.

Esta separación entre falsos positivos y amenazas reales es lo que cambia la calidad del diagnóstico. Sin contexto de ataque, tratás todos los hallazgos del escáner con la misma urgencia. Con el log del firewall como contexto, podés priorizar y actuar primero sobre lo que realmente fue atacado.

WAF + escáner + revisión de logs es la combinación que da cobertura real. Ninguno de los tres solo alcanza.

Pasos para limpiar el núcleo de WordPress

El orden importa. Si saltás pasos, el malware vuelve.

• Backup completo primero: aunque el sitio esté infectado, necesitás el backup para recuperar contenido legítimo. WPVivid o Duplicator sirven. Si el hosting está suspendido, descargá los archivos por FTP.
• Activá modo mantenimiento: para que nadie más se infecte mientras trabajás.
• Descargá el core limpio: bajá la versión exacta de WordPress que tenés desde WordPress.org y subí todos los archivos excepto wp-content y wp-config.php. Esto sobreescribe el core sin tocar tu contenido.
• Verificá integridad: usá Wordfence o el plugin Integrity Checker para confirmar que los archivos del core coinciden con los originales.

El método oficial de WordPress.org para reinstalar el core es directo: subís los archivos y pisás lo que estaba. No borrés wp-config.php ni wp-content, ahí está tu base de datos y tus archivos de usuario.

Limpiar plugins, temas y base de datos

Los plugins y temas son el vector de entrada más común. La estrategia más efectiva no es «limpiar» el código infectado, es borrarlo y reinstalarlo desde cero. Cubrimos ese tema en detalle en usar formularios con validación segura.

Para cada plugin activo: desactivalo, borralo, reinstalalo desde el repositorio oficial. Si el plugin es premium y no tenés licencia activa, eso es un problema aparte, pero no instalés la versión nulleada de nuevo. Probablemente eso fue lo que te infectó en primer lugar.

Para el tema: mismo proceso. Si tiene customizaciones, vas a tener que recuperarlas del backup limpio. El tema child ayuda a que las customizaciones estén separadas del tema padre y el proceso de limpieza sea menos destructivo.

Para la base de datos, exportá un dump SQL completo desde phpMyAdmin y abrilo en un editor de texto. Buscá patrones como <script src="http, eval(, base64_decode, y URLs que no reconocés. Si encontrás en wp_options una opción con un valor que incluye código JavaScript, eso es malware.

El warning más importante acá: los backdoors. El malware inteligente instala una puerta trasera separada del código infectado. Si solo limpiás lo visible sin buscar el backdoor, el sitio vuelve a infectarse en días. Buscá archivos PHP en wp-content/uploads (donde no debería haber PHP), archivos con nombres genéricos en rutas inusuales, y funciones que acepten input externo y lo ejecuten.

Tabla comparativa: escáneres según contexto de uso

La columna que más importa en la práctica es «contexto de ataque en resultados». Ninguno de los escáneres populares lo provee de forma integrada. Eso significa que cruzar el resultado del escaneo con los logs del firewall siempre es un paso manual, independientemente de la herramienta que uses.

Preguntas frecuentes

¿Por qué mi escáner de malware de WordPress se detiene en el 48%?

El escáner no se detuvo visualmente, pero el proceso PHP que lo ejecuta sí. En hosting compartido, el límite de ejecución PHP (max_execution_time) suele estar entre 30 y 90 segundos. Cuando un sitio tiene más de 40.000-50.000 archivos, el escaneo supera ese límite y la request AJAX muere. El JavaScript de la interfaz no detecta el error y la barra sigue moviéndose. Para verificar si pasó, revisá la cantidad de archivos escaneados en el resumen final de Wordfence y comparala con el total real del sitio.

¿Wordfence y Sucuri detectan realmente todo el malware?

No. Ambos dependen principalmente de comparación de firmas contra bases de datos de malware conocido. El malware que usa ofuscación avanzada, encriptación o técnicas de evasión activas puede no coincidir con ninguna firma. Además, si el escaneo se interrumpe por timeout en sitios grandes, hay archivos que directamente no se analizan. La cobertura real en producción es menor que la que muestra cualquier demo o marketing del producto.

¿Qué información me oculta el escáner de malware?

El escáner te dice si un archivo coincide con un patrón sospechoso, pero no te dice si ese archivo fue realmente atacado. No cruza los resultados con los logs del firewall, no consulta si hubo requests hacia esa ruta, no te informa si el archivo fue modificado durante un período de actividad anómala. Esa información existe en el servidor (en los logs de Wordfence, en los logs de acceso del hosting, en el WAF), pero hay que ir a buscarla por separado y cruzarla manualmente con los hallazgos del escaneo.

¿Cómo puedo saber si un archivo fue realmente atacado o es un falso positivo?

Combinando el resultado del escáner con los logs del firewall. Si el escáner marca un archivo como sospechoso, buscá en los logs de Wordfence (Firewall > Blocked Attacks) si hubo requests hacia esa ruta en las últimas semanas. Si el archivo lleva más de un año sin modificaciones y no aparece en ningún intento bloqueado, es candidato a falso positivo. Si hay intentos de acceso recientes contra esa ruta y la fecha de modificación del archivo coincide con esa actividad, es una amenaza que priorizar.

Conclusión

Los escáneres de malware para WordPress son herramientas útiles con limitaciones de diseño que pocos usuarios conocen. La más grave es que se prueban en instalaciones simples y fallan silenciosamente en sitios de producción reales con volúmenes altos de archivos. La segunda es que detectan patrones sospechosos sin darte el contexto de si alguien realmente atacó esos archivos.

Eso no significa que sean inútiles. Significa que usarlos bien requiere saber qué esperar de ellos y qué compensar manualmente. Un escaneo incompleto que no detectó el timeout es peor que no escanear, porque te da una falsa sensación de seguridad. Un hallazgo sin contexto de ataque que tratás como amenaza crítica te hace perder tiempo en falsos positivos mientras el problema real sigue sin atención.

El enfoque que cierra esas brechas es combinar el escaneo por etapas con revisión activa de logs del firewall. WAF activo, escaneo periódico dividido para asegurar cobertura completa, y cruzamiento manual de hallazgos con registros de actividad. No es el flujo de un clic que venden los plugins, pero es el que funciona en sitios reales.

Fuentes

• The Two Things Every WordPress Scanner Gets Wrong on Real Sites — NovaHeaven
• Wordfence Scan Troubleshooting — documentación oficial
• Detección de malware WordPress con IA y Wordfence — Blog Donweb
• Logs de seguridad en WordPress — Limpia Tu Web