Si index.php vuelve a aparecer infectado después de sustituirlo, el archivo no es la causa raíz. Restaurar core es sencillo; una reinfección indica que algún proceso, cuenta o mecanismo de persistencia todavía puede volver a escribirlo.
Demuestra cuándo y cómo cambia index.php
Parte de una copia de core fiable, registra hash y fecha de modificación y espera al siguiente cambio. Cruza la hora con peticiones web, ejecución de cron, actividad de plugins, despliegues y eventos del servidor. Lo importante es identificar quién escribe el archivo.
Separa corrupción de core y persistencia activa
- Compara los archivos de core con la release exacta de WordPress.
- Revisa PHP modificado recientemente fuera de core, sobre todo en rutas escribibles.
- Inspecciona tareas programadas, MU plugins y loaders de tema o plugin.
- Comprueba si alguna automatización legítima del hosting o despliegue modifica el archivo.
Busca el componente que puede volver a escribirlo
La persistencia puede vivir en un plugin comprometido, un loader oculto, una tarea programada o un proceso del servidor. Si también cambia .htaccess, utiliza el diagnóstico de .htaccess que se reescribe. Si los cambios coinciden con ejecuciones programadas, revisa tareas cron maliciosas en WordPress.
Restaura desde un baseline fiable solo después de contener
- Conserva el archivo infectado y los logs relevantes.
- Aísla o desactiva el escritor confirmado.
- Reinstala core, plugins o tema afectados desde paquetes fiables.
- Rota credenciales que todavía puedan dar acceso de escritura.
- Revisa propiedad y rutas escribibles antes de volver al tráfico normal.
No sustituyas index.php periódicamente como “solución”
Eso puede ocultar la recurrencia mientras el escritor sigue activo y elimina timestamps útiles para atribuir la reinfección.
Criterio de salida
El caso solo puede cerrarse cuando el hash de core permanece estable con tráfico, cron y reinicios normales, ningún proceso desconocido vuelve a escribir el archivo y la vía de persistencia ha sido eliminada.