Un checksum del núcleo de WordPress que no coincide indica que uno o más archivos de core son distintos de la release fiable esperada. No explica la causa. Puede ser una actualización incompleta, un cambio manual, corrupción del sistema de archivos o un compromiso; primero hay que clasificar el cambio.
Confirma la versión exacta de WordPress antes de comparar
Los checksums solo tienen sentido contra la release correspondiente. Registra versión instalada y qué archivos fallan. Separa archivos ausentes, modificados y añadidos inesperadamente.
Qué puede indicar el patrón de diferencias
- Pocos archivos tras una actualización pueden apuntar a un despliegue parcial.
- Un core editado manualmente puede ser historia legítima, pero no debería quedarse en core.
- PHP inesperado o cambios sin propietario conocido necesitan triaje de incidente.
- Si el cambio reaparece tras sustituir el archivo, existe un escritor activo.
Conserva evidencia antes de restaurar core fiable
Guarda hashes, timestamps y copias de los archivos sospechosos fuera de rutas ejecutables. Compara el alcance con el triaje de cambios de integridad.
Restaura core sin sobrescribir el contenido de la aplicación
- Haz backup y conserva los archivos sospechosos.
- Sustituye únicamente el core desde la release exacta y fiable.
- No sobrescribas
wp-contentni configuración en un refresco a ciegas. - Corrige la vía de actualización/despliegue o elimina al escritor que causaba el cambio.
Un checksum limpio no demuestra por sí solo que la incidencia haya terminado
Un refresco de core puede eliminar temporalmente archivos alterados mientras un plugin, cuenta o tarea comprometidos aún pueden volver a escribirlos.
Verificación
Repite la comparación tras tráfico normal, tareas programadas y despliegues. El mismo core fiable debe mantenerse estable y no debe reaparecer ningún archivo inexplicado.