Una alerta de integridad es evidencia, no una sentencia: saber que un archivo ha cambiado solo es útil si puedes compararlo con un despliegue esperado, una versión oficial o una edición autorizada.
Compara los cambios con una fuente de confianza
Exporta el conjunto completo de archivos añadidos, modificados y eliminados con hashes y timestamps. Crúzalo con actualizaciones, despliegues y actividad de administradores antes de restaurar nada.
Conserva el cambio antes de sustituirlo
Un reemplazo inmediato puede borrar un hotfix legítimo o evidencia de un ataque. Guarda los archivos sospechosos y los logs relacionados, especialmente si el cambio no tiene un actor conocido.
Prioriza las rutas de mayor riesgo
- PHP ejecutable dentro de uploads.
- Raíz del sitio y archivos de bootstrap.
mu-pluginsy plugins modificados.- Directorios recientemente escribibles o con propiedad inesperada.
¿Actualización legítima, hotfix o escritura inexplicada?
Una actualización controlada debe corresponder a una release y una ventana de despliegue. Un hotfix manual puede ser legítimo, pero debe tener autor. Un cambio sin paquete, operador ni justificación obliga a investigar compromiso o despliegue fallido.
Relaciona la alerta con el tipo de archivo
Si afecta a core, compáralo con los checksums oficiales de WordPress. Si es .htaccess y vuelve a cambiar después de restaurarlo, sigue el diagnóstico de .htaccess que se reescribe continuamente.
No apruebes un nuevo baseline mientras quede un cambio sin explicar
Si lo haces, conviertes el archivo sospechoso en “conocido como bueno” y pierdes una de las señales más valiosas de recurrencia.
Cómo validar el nuevo baseline
Cada archivo modificado debe tener una fuente documentada o haber sido retirado, los paquetes de confianza deben coincidir con disco y la monitorización no debe detectar escrituras inexplicadas durante actualizaciones y tráfico normales.