Malware reescribe index.php en WordPress, limpiar

Cuando toca limpiar malware wordpress y aparece un index.php infectado, el problema no suele resolverse borrando una línea rara y dando el incidente por cerrado. Ese archivo puede ser solo la parte visible de una intrusión más amplia: una puerta trasera en un plugin, cambios en wp-config.php, reglas maliciosas en .htaccess o usuarios con privilegios indebidos.

Si un malware reescribe index.php wordpress, significa que ha modificado el archivo de inicio para ejecutar código no autorizado, redirigir visitas o cargar instrucciones ocultas. La vía correcta de limpieza es contener el incidente, revisar la integridad del core y del entorno completo, eliminar la persistencia y validar después que no haya reinfección.

Qué significa que un malware reescriba index.php en WordPress

En WordPress, index.php forma parte del arranque básico del sitio. Si ha sido reescrito, puede haberse insertado código para cargar scripts externos, ocultar spam SEO, provocar redirecciones o reactivar otros componentes maliciosos. No siempre será el punto de entrada: a menudo es el lugar donde el atacante deja una ejecución visible.

Por eso conviene distinguir entre restaurar un archivo y limpiar la infección completa. Dejar un index.php limpio mientras sigue existiendo la causa original suele terminar en una nueva alteración del archivo.

Cómo identificar si index.php está infectado o ha sido modificado

Las señales más habituales son redirecciones inesperadas, alertas del hosting, bloqueos del navegador, páginas en blanco, inyecciones de spam en resultados de búsqueda o cambios de fecha en archivos del core. También puede haber usuarios administradores no reconocidos o tareas que reaparecen tras borrarlas.

A nivel técnico, hay que comprobar si el contenido de index.php coincide con la versión oficial de WordPress que usa el sitio. El código ofuscado, cadenas largas sin sentido, llamadas a archivos en rutas inusuales o cargas remotas son indicadores a revisar, aunque el contexto importa y no todo fragmento extraño confirma malware por sí solo.

• Comparar la integridad del core con una copia oficial de la misma versión.
• Revisar fechas de modificación en archivos sensibles.
• Comprobar si el problema afecta solo al frontal o también al panel.

Qué hacer antes de tocar archivos: copia, aislamiento y revisión del acceso

Antes de editar nada, conviene hacer una copia forense de archivos y base de datos. Aunque el sitio esté comprometido, esa copia puede servir para análisis posterior si reaparece la infección o si hay que reconstruir la cronología.

Después, según el entorno, puede ser razonable poner el sitio en mantenimiento o restringir accesos temporalmente para evitar más daño. También hay que revisar credenciales: administrador de WordPress, SFTP/FTP, panel del hosting, base de datos y cuentas de correo relacionadas. Si una contraseña está comprometida, limpiar archivos sin rotarla deja el incidente abierto.

Cómo limpiar WordPress cuando index.php ha sido alterado

Hay dos enfoques habituales: restauración desde copia limpia o limpieza manual. Restaurar puede encajar si existe una copia verificada previa al incidente y el sitio no ha cambiado mucho desde entonces. La limpieza manual suele ser necesaria cuando no hay backup fiable o cuando conviene preservar contenido reciente.

En ambos casos, no basta con sustituir index.php. Hay que revisar como mínimo:

• Core de WordPress y su integridad.
• Plugins, temas activos e inactivos, y mu-plugins.
• Carpeta uploads en busca de PHP no esperados.
• wp-config.php, .htaccess y otros archivos de arranque.
• Usuarios, tareas programadas, opciones sospechosas en base de datos y posibles puertas traseras.

Si se reemplazan archivos del core por versiones oficiales y se eliminan extensiones abandonadas o comprometidas, el paso siguiente es actualizar todo lo que permanezca en uso y reinstalar solo software de origen fiable.

Qué revisar después para confirmar que el sitio está realmente limpio

La validación posterior es clave para no confundir limpieza con apariencia de normalidad. Conviene comprobar que no reaparecen cambios en index.php, que no hay nuevos usuarios ni archivos extraños y que el sitio responde igual para administradores y visitantes.

Si el hosting ofrece registros, merece la pena revisar accesos, errores y eventos cercanos al incidente. También ayuda combinar revisión de integridad, escaneo de archivos y monitorización durante varios días. Si vuelve a modificarse un archivo, probablemente sigue existiendo persistencia.

Cómo evitar que el problema vuelva a ocurrir

El hardening wordpress posterior debe centrarse en medidas razonables y mantenibles: actualizaciones del core, plugins y temas; contraseñas robustas; doble factor donde sea posible; mínimos privilegios; copias verificadas; y retirada de software abandonado.

Según el proveedor, también puede encajar un WAF, reglas de seguridad del hosting, revisión de permisos de archivos y alertas de cambios en ficheros críticos. La documentación oficial de WordPress sobre endurecimiento del sitio es una referencia útil para ordenar estas tareas.

Cuándo conviene pedir soporte profesional

Si hay reinfección, código ofuscado en varios puntos, dudas sobre el origen de la intrusión, caída del panel o impacto en varios sitios de la misma cuenta, conviene escalar el caso. También si el sitio maneja negocio activo, campañas en marcha o datos sensibles y no hay margen para pruebas inseguras.

En un sitio hackeado wordpress, limpiar solo el síntoma suele alargar el problema. Lo prudente es verificar todo el entorno, confirmar la integridad del core y cerrar la vía de acceso antes de darlo por resuelto. Si persisten señales de compromiso o prefieres una restauración segura con criterio técnico, pedir soporte wordpress o mantenimiento wordpress puede ahorrar tiempo, riesgo y nuevas caídas.